Commit 4eb766f6 authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'devicetree-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

Pull devicetree updates from Rob Herring:
 "Bindings:

   - DT schema conversions for Samsung clocks, RNG bindings, Qcom
     Command DB and rmtfs, gpio-restart, i2c-mux-gpio, i2c-mux-pinctl,
     Tegra I2C and BPMP, pwm-vibrator, Arm DSU, and Cadence macb

   - DT schema conversions for Broadcom platforms: interrupt
     controllers, STB GPIO, STB waketimer, STB reset, iProc MDIO mux,
     iProc PCIe, Cygnus PCIe PHY, PWM, USB BDC, BCM6328 LEDs, TMON,
     SYSTEMPORT, AMAC, Northstar 2 PCIe PHY, GENET, moca PHY, GISB
     arbiter, and SATA

   - Add binding schemas for Tegra210 EMC table, TI DC-DC converters,

   - Clean-ups of MDIO bus schemas to fix 'unevaluatedProperties' issues

   - More fixes due to 'unevaluatedProperties' enabling

   - Data type fixes and clean-ups of binding examples found in
     preparation to move to validating DTB files directly (instead of
     intermediate YAML representation.

   - Vendor prefixes for T-Head Semiconductor, OnePlus, and Sunplus

   - Add various new compatible strings

  DT core:

   - Silence a warning for overlapping reserved memory regions

   - Reimplement unittest overlay tracking

   - Fix stack frame size warning in unittest

   - Clean-ups of early FDT scanning functions

   - Fix handling of "linux,usable-memory-range" on EFI booted systems

   - Add support for 'fail' status on CPU nodes

   - Improve error message in of_phandle_iterator_next()

   - kbuild: Disable duplicate unit-address warnings for disabled nodes"

* tag 'devicetree-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (114 commits)
  dt-bindings: net: mdio: Drop resets/reset-names child properties
  dt-bindings: clock: samsung: convert S5Pv210 to dtschema
  dt-bindings: clock: samsung: convert Exynos5410 to dtschema
  dt-bindings: clock: samsung: convert Exynos5260 to dtschema
  dt-bindings: clock: samsung: extend Exynos7 bindings with UFS
  dt-bindings: clock: samsung: convert Exynos7 to dtschema
  dt-bindings: clock: samsung: convert Exynos5433 to dtschema
  dt-bindings: i2c: maxim,max96712: Add bindings for Maxim Integrated MAX96712
  dt-bindings: iio: adi,ltc2983: Fix 64-bit property sizes
  dt-bindings: power: maxim,max17040: Fix incorrect type for 'maxim,rcomp'
  dt-bindings: interrupt-controller: arm,gic-v3: Fix 'interrupts' cell size in example
  dt-bindings: iio/magnetometer: yamaha,yas530: Fix invalid 'interrupts' in example
  dt-bindings: clock: imx5: Drop clock consumer node from example
  dt-bindings: Drop required 'interrupt-parent'
  dt-bindings: net: ti,dp83869: Drop value on boolean 'ti,max-output-impedance'
  dt-bindings: net: wireless: mt76: Fix 8-bit property sizes
  dt-bindings: PCI: snps,dw-pcie-ep: Drop conflicting 'max-functions' schema
  dt-bindings: i2c: st,stm32-i2c: Make each example a separate entry
  dt-bindings: net: stm32-dwmac: Make each example a separate entry
  dt-bindings: net: Cleanup MDIO node schemas
  ...
parents ce990f1d e623611b
......@@ -65,7 +65,9 @@ DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_all_cmd)))
override DTC_FLAGS := \
-Wno-avoid_unnecessary_addr_size \
-Wno-graph_child_address \
-Wno-interrupt_provider
-Wno-interrupt_provider \
-Wno-unique_unit_address \
-Wunique_unit_address_if_enabled
# Disable undocumented compatible checks until warning free
override DT_CHECKER_FLAGS ?=
......
......@@ -166,16 +166,6 @@ examples:
};
};
dma0: dma@3000000 {
/* compatible = "arm,pl330", "arm,primecell"; */
cci-control-port = <&cci_control0>;
reg = <0x0 0x3000000 0x0 0x1000>;
interrupts = <10>;
#dma-cells = <1>;
#dma-channels = <8>;
#dma-requests = <32>;
};
cci@2c090000 {
compatible = "arm,cci-400";
#address-cells = <1>;
......
* ARM DynamIQ Shared Unit (DSU) Performance Monitor Unit (PMU)
ARM DyanmIQ Shared Unit (DSU) integrates one or more CPU cores
with a shared L3 memory system, control logic and external interfaces to
form a multicore cluster. The PMU enables to gather various statistics on
the operations of the DSU. The PMU provides independent 32bit counters that
can count any of the supported events, along with a 64bit cycle counter.
The PMU is accessed via CPU system registers and has no MMIO component.
** DSU PMU required properties:
- compatible : should be one of :
"arm,dsu-pmu"
- interrupts : Exactly 1 SPI must be listed.
- cpus : List of phandles for the CPUs connected to this DSU instance.
** Example:
dsu-pmu-0 {
compatible = "arm,dsu-pmu";
interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>;
cpus = <&cpu_0>, <&cpu_1>;
};
......@@ -137,6 +137,9 @@ properties:
- arm,cortex-a75
- arm,cortex-a76
- arm,cortex-a77
- arm,cortex-a78
- arm,cortex-a510
- arm,cortex-a710
- arm,cortex-m0
- arm,cortex-m0+
- arm,cortex-m1
......@@ -145,8 +148,12 @@ properties:
- arm,cortex-r4
- arm,cortex-r5
- arm,cortex-r7
- arm,cortex-x1
- arm,cortex-x2
- arm,neoverse-e1
- arm,neoverse-n1
- arm,neoverse-n2
- arm,neoverse-v1
- brcm,brahma-b15
- brcm,brahma-b53
- brcm,vulcan
......
......@@ -44,10 +44,18 @@ properties:
- arm,cortex-a76-pmu
- arm,cortex-a77-pmu
- arm,cortex-a78-pmu
- arm,cortex-a510-pmu
- arm,cortex-a710-pmu
- arm,cortex-x1-pmu
- arm,cortex-x2-pmu
- arm,neoverse-e1-pmu
- arm,neoverse-n1-pmu
- arm,neoverse-n2-pmu
- arm,neoverse-v1-pmu
- brcm,vulcan-pmu
- cavium,thunder-pmu
- nvidia,denver-pmu
- nvidia,carmel-pmu
- qcom,krait-pmu
- qcom,scorpion-pmu
- qcom,scorpion-mp-pmu
......
......@@ -20,6 +20,11 @@ properties:
- const: st-ericsson,mop500
- const: st-ericsson,u8500
- description: ST-Ericsson HREF520
items:
- const: st-ericsson,href520
- const: st-ericsson,u8500
- description: ST-Ericsson HREF (v60+)
items:
- const: st-ericsson,hrefv60+
......@@ -30,9 +35,34 @@ properties:
- const: calaosystems,snowball-a9500
- const: st-ericsson,u9500
- description: Samsung Galaxy Ace 2 (GT-I8160)
items:
- const: samsung,codina
- const: st-ericsson,u8500
- description: Samsung Galaxy Beam (GT-I8530)
items:
- const: samsung,gavini
- const: st-ericsson,u8500
- description: Samsung Galaxy S III mini (GT-I8190)
items:
- const: samsung,golden
- const: st-ericsson,u8500
- description: Samsung Galaxy S Advance (GT-I9070)
items:
- const: samsung,janice
- const: st-ericsson,u8500
- description: Samsung Galaxy Amp (SGH-I407)
items:
- const: samsung,kyle
- const: st-ericsson,u8500
- description: Samsung Galaxy XCover 2 (GT-S7710)
items:
- const: samsung,skomer
- const: st-ericsson,u8500
additionalProperties: true
* Broadcom SATA3 AHCI Controller
SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
Required properties:
- compatible : should be one or more of
"brcm,bcm7216-ahci"
"brcm,bcm7425-ahci"
"brcm,bcm7445-ahci"
"brcm,bcm-nsp-ahci"
"brcm,sata3-ahci"
"brcm,bcm63138-ahci"
- reg : register mappings for AHCI and SATA_TOP_CTRL
- reg-names : "ahci" and "top-ctrl"
- interrupts : interrupt mapping for SATA IRQ
Optional properties:
- reset: for "brcm,bcm7216-ahci" must be a valid reset phandle
pointing to the RESCAL reset controller provider node.
- reset-names: for "brcm,bcm7216-ahci", must be "rescal".
Also see ahci-platform.txt.
Example:
sata@f045a000 {
compatible = "brcm,bcm7445-ahci", "brcm,sata3-ahci";
reg = <0xf045a000 0xa9c>, <0xf0458040 0x24>;
reg-names = "ahci", "top-ctrl";
interrupts = <0 30 0>;
#address-cells = <1>;
#size-cells = <0>;
sata0: sata-port@0 {
reg = <0>;
phys = <&sata_phy 0>;
};
sata1: sata-port@1 {
reg = <1>;
phys = <&sata_phy 1>;
};
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/ata/brcm,sata-brcm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom SATA3 AHCI Controller
description:
SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
allOf:
- $ref: sata-common.yaml#
properties:
compatible:
oneOf:
- items:
- enum:
- brcm,bcm7216-ahci
- brcm,bcm7445-ahci
- brcm,bcm7425-ahci
- brcm,bcm63138-ahci
- const: brcm,sata3-ahci
- items:
- const: brcm,bcm-nsp-ahci
reg:
minItems: 2
maxItems: 2
reg-names:
items:
- const: ahci
- const: top-ctrl
interrupts:
maxItems: 1
dma-coherent: true
if:
properties:
compatible:
contains:
enum:
- brcm,bcm7216-ahci
- brcm,bcm63138-ahci
then:
properties:
resets:
maxItems: 1
reset-names:
enum:
- rescal
- ahci
required:
- compatible
- reg
- interrupts
- "#address-cells"
- "#size-cells"
unevaluatedProperties: false
examples:
- |
sata@f045a000 {
compatible = "brcm,bcm7445-ahci", "brcm,sata3-ahci";
reg = <0xf045a000 0xa9c>, <0xf0458040 0x24>;
reg-names = "ahci", "top-ctrl";
interrupts = <0 30 0>;
#address-cells = <1>;
#size-cells = <0>;
sata0: sata-port@0 {
reg = <0>;
phys = <&sata_phy 0>;
};
sata1: sata-port@1 {
reg = <1>;
phys = <&sata_phy 1>;
};
};
Broadcom GISB bus Arbiter controller
Required properties:
- compatible:
"brcm,bcm7278-gisb-arb" for V7 28nm chips
"brcm,gisb-arb" or "brcm,bcm7445-gisb-arb" for other 28nm chips
"brcm,bcm7435-gisb-arb" for newer 40nm chips
"brcm,bcm7400-gisb-arb" for older 40nm chips and all 65nm chips
"brcm,bcm7038-gisb-arb" for 130nm chips
- reg: specifies the base physical address and size of the registers
- interrupts: specifies the two interrupts (timeout and TEA) to be used from
the parent interrupt controller. A third optional interrupt may be specified
for breakpoints.
Optional properties:
- brcm,gisb-arb-master-mask: 32-bits wide bitmask used to specify which GISB
masters are valid at the system level
- brcm,gisb-arb-master-names: string list of the litteral name of the GISB
masters. Should match the number of bits set in brcm,gisb-master-mask and
the order in which they appear
Example:
gisb-arb@f0400000 {
compatible = "brcm,gisb-arb";
reg = <0xf0400000 0x800>;
interrupts = <0>, <2>;
interrupt-parent = <&sun_l2_intc>;
brcm,gisb-arb-master-mask = <0x7>;
brcm,gisb-arb-master-names = "bsp_0", "scpu_0", "cpu_0";
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/brcm,gisb-arb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom GISB bus Arbiter controller
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
compatible:
oneOf:
- items:
- enum:
- brcm,bcm7445-gisb-arb # for other 28nm chips
- const: brcm,gisb-arb
- items:
- enum:
- brcm,bcm7278-gisb-arb # for V7 28nm chips
- brcm,bcm7435-gisb-arb # for newer 40nm chips
- brcm,bcm7400-gisb-arb # for older 40nm chips and all 65nm chips
- brcm,bcm7038-gisb-arb # for 130nm chips
- brcm,gisb-arb # fallback compatible
reg:
maxItems: 1
interrupts:
minItems: 2
items:
- description: timeout interrupt line
- description: target abort interrupt line
- description: breakpoint interrupt line
brcm,gisb-arb-master-mask:
$ref: /schemas/types.yaml#/definitions/uint32
description: >
32-bits wide bitmask used to specify which GISB masters are valid at the
system level
brcm,gisb-arb-master-names:
$ref: /schemas/types.yaml#/definitions/string-array
description: >
String list of the litteral name of the GISB masters. Should match the
number of bits set in brcm,gisb-master-mask and the order in which they
appear from MSB to LSB.
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
gisb-arb@f0400000 {
compatible = "brcm,gisb-arb";
reg = <0xf0400000 0x800>;
interrupts = <0>, <2>;
interrupt-parent = <&sun_l2_intc>;
brcm,gisb-arb-master-mask = <0x7>;
brcm,gisb-arb-master-names = "bsp_0", "scpu_0", "cpu_0";
};
* Samsung Exynos5260 Clock Controller
Exynos5260 has 13 clock controllers which are instantiated
independently from the device-tree. These clock controllers
generate and supply clocks to various hardware blocks within
the SoC.
Each clock is assigned an identifier and client nodes can use
this identifier to specify the clock which they consume. All
available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos5260-clk.h header and can be used in
device tree sources.
External clocks:
There are several clocks that are generated outside the SoC. It
is expected that they are defined using standard clock bindings
with following clock-output-names:
- "fin_pll" - PLL input clock from XXTI
- "xrtcxti" - input clock from XRTCXTI
- "ioclk_pcm_extclk" - pcm external operation clock
- "ioclk_spdif_extclk" - spdif external operation clock
- "ioclk_i2s_cdclk" - i2s0 codec clock
Phy clocks:
There are several clocks which are generated by specific PHYs.
These clocks are fed into the clock controller and then routed to
the hardware blocks. These clocks are defined as fixed clocks in the
driver with following names:
- "phyclk_dptx_phy_ch3_txd_clk" - dp phy clock for channel 3
- "phyclk_dptx_phy_ch2_txd_clk" - dp phy clock for channel 2
- "phyclk_dptx_phy_ch1_txd_clk" - dp phy clock for channel 1
- "phyclk_dptx_phy_ch0_txd_clk" - dp phy clock for channel 0
- "phyclk_hdmi_phy_tmds_clko" - hdmi phy tmds clock
- "phyclk_hdmi_phy_pixel_clko" - hdmi phy pixel clock
- "phyclk_hdmi_link_o_tmds_clkhi" - hdmi phy for hdmi link
- "phyclk_dptx_phy_o_ref_clk_24m" - dp phy reference clock
- "phyclk_dptx_phy_clk_div2"
- "phyclk_mipi_dphy_4l_m_rxclkesc0"
- "phyclk_usbhost20_phy_phyclock" - usb 2.0 phy clock
- "phyclk_usbhost20_phy_freeclk"
- "phyclk_usbhost20_phy_clk48mohci"
- "phyclk_usbdrd30_udrd30_pipe_pclk"
- "phyclk_usbdrd30_udrd30_phyclock" - usb 3.0 phy clock
Required Properties for Clock Controller:
- compatible: should be one of the following.
1) "samsung,exynos5260-clock-top"
2) "samsung,exynos5260-clock-peri"
3) "samsung,exynos5260-clock-egl"
4) "samsung,exynos5260-clock-kfc"
5) "samsung,exynos5260-clock-g2d"
6) "samsung,exynos5260-clock-mif"
7) "samsung,exynos5260-clock-mfc"
8) "samsung,exynos5260-clock-g3d"
9) "samsung,exynos5260-clock-fsys"
10) "samsung,exynos5260-clock-aud"
11) "samsung,exynos5260-clock-isp"
12) "samsung,exynos5260-clock-gscl"
13) "samsung,exynos5260-clock-disp"
- reg: physical base address of the controller and the length of
memory mapped region.
- #clock-cells: should be 1.
- clocks: list of clock identifiers which are fed as the input to
the given clock controller. Please refer the next section to find
the input clocks for a given controller.
- clock-names: list of names of clocks which are fed as the input
to the given clock controller.
Input clocks for top clock controller:
- fin_pll
- dout_mem_pll
- dout_bus_pll
- dout_media_pll
Input clocks for peri clock controller:
- fin_pll
- ioclk_pcm_extclk
- ioclk_i2s_cdclk
- ioclk_spdif_extclk
- phyclk_hdmi_phy_ref_cko
- dout_aclk_peri_66
- dout_sclk_peri_uart0
- dout_sclk_peri_uart1
- dout_sclk_peri_uart2
- dout_sclk_peri_spi0_b
- dout_sclk_peri_spi1_b
- dout_sclk_peri_spi2_b
- dout_aclk_peri_aud
- dout_sclk_peri_spi0_b
Input clocks for egl clock controller:
- fin_pll
- dout_bus_pll
Input clocks for kfc clock controller:
- fin_pll
- dout_media_pll
Input clocks for g2d clock controller:
- fin_pll
- dout_aclk_g2d_333
Input clocks for mif clock controller:
- fin_pll
Input clocks for mfc clock controller:
- fin_pll
- dout_aclk_mfc_333
Input clocks for g3d clock controller:
- fin_pll
Input clocks for fsys clock controller:
- fin_pll
- phyclk_usbhost20_phy_phyclock
- phyclk_usbhost20_phy_freeclk
- phyclk_usbhost20_phy_clk48mohci
- phyclk_usbdrd30_udrd30_pipe_pclk
- phyclk_usbdrd30_udrd30_phyclock
- dout_aclk_fsys_200
Input clocks for aud clock controller:
- fin_pll
- fout_aud_pll
- ioclk_i2s_cdclk
- ioclk_pcm_extclk
Input clocks for isp clock controller:
- fin_pll
- dout_aclk_isp1_266
- dout_aclk_isp1_400
- mout_aclk_isp1_266
Input clocks for gscl clock controller:
- fin_pll
- dout_aclk_gscl_400
- dout_aclk_gscl_333
Input clocks for disp clock controller:
- fin_pll
- phyclk_dptx_phy_ch3_txd_clk
- phyclk_dptx_phy_ch2_txd_clk
- phyclk_dptx_phy_ch1_txd_clk
- phyclk_dptx_phy_ch0_txd_clk
- phyclk_hdmi_phy_tmds_clko
- phyclk_hdmi_phy_ref_clko
- phyclk_hdmi_phy_pixel_clko
- phyclk_hdmi_link_o_tmds_clkhi
- phyclk_mipi_dphy_4l_m_txbyte_clkhs
- phyclk_dptx_phy_o_ref_clk_24m
- phyclk_dptx_phy_clk_div2
- phyclk_mipi_dphy_4l_m_rxclkesc0
- phyclk_hdmi_phy_ref_cko
- ioclk_spdif_extclk
- dout_aclk_peri_aud
- dout_aclk_disp_222
- dout_sclk_disp_pixel
- dout_aclk_disp_333
Example 1: An example of a clock controller node is listed below.
clock_mfc: clock-controller@11090000 {
compatible = "samsung,exynos5260-clock-mfc";
clock = <&fin_pll>, <&clock_top TOP_DOUT_ACLK_MFC_333>;
clock-names = "fin_pll", "dout_aclk_mfc_333";
reg = <0x11090000 0x10000>;
#clock-cells = <1>;
};
Example 2: UART controller node that consumes the clock generated by the
peri clock controller. Refer to the standard clock bindings for
information about 'clocks' and 'clock-names' property.
serial@12c00000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
interrupts = <0 146 0>;
clocks = <&clock_peri PERI_PCLK_UART0>, <&clock_peri PERI_SCLK_UART0>;
clock-names = "uart", "clk_uart_baud0";
};
* Samsung Exynos5410 Clock Controller
The Exynos5410 clock controller generates and supplies clock to various
controllers within the Exynos5410 SoC.
Required Properties:
- compatible: should be "samsung,exynos5410-clock"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- clocks: should contain an entry specifying the root clock from external
oscillator supplied through XXTI or XusbXTI pin. This clock should be
defined using standard clock bindings with "fin_pll" clock-output-name.
That clock is being passed internally to the 9 PLLs.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos5410.h header and can be used in device
tree sources.
Example 1: An example of a clock controller node is listed below.
fin_pll: xxti {
compatible = "fixed-clock";
clock-frequency = <24000000>;
clock-output-names = "fin_pll";
#clock-cells = <0>;
};
clock: clock-controller@10010000 {
compatible = "samsung,exynos5410-clock";
reg = <0x10010000 0x30000>;
#clock-cells = <1>;
clocks = <&fin_pll>;
};
Example 2: UART controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
serial@12c20000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
interrupts = <0 51 0>;
clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>;
clock-names = "uart", "clk_uart_baud0";
};
* Samsung Exynos7 Clock Controller
Exynos7 clock controller has various blocks which are instantiated
independently from the device-tree. These clock controllers
generate and supply clocks to various hardware blocks within
the SoC.
Each clock is assigned an identifier and client nodes can use
this identifier to specify the clock which they consume. All
available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos7-clk.h header and can be used in
device tree sources.
External clocks:
There are several clocks that are generated outside the SoC. It
is expected that they are defined using standard clock bindings
with following clock-output-names:
- "fin_pll" - PLL input clock from XXTI
Required Properties for Clock Controller:
- compatible: clock controllers will use one of the following
compatible strings to indicate the clock controller
functionality.
- "samsung,exynos7-clock-topc"
- "samsung,exynos7-clock-top0"
- "samsung,exynos7-clock-top1"
- "samsung,exynos7-clock-ccore"
- "samsung,exynos7-clock-peric0"
- "samsung,exynos7-clock-peric1"
- "samsung,exynos7-clock-peris"
- "samsung,exynos7-clock-fsys0"
- "samsung,exynos7-clock-fsys1"
- "samsung,exynos7-clock-mscl"
- "samsung,exynos7-clock-aud"
- reg: physical base address of the controller and the length of
memory mapped region.
- #clock-cells: should be 1.
- clocks: list of clock identifiers which are fed as the input to
the given clock controller. Please refer the next section to
find the input clocks for a given controller.
- clock-names: list of names of clocks which are fed as the input
to the given clock controller.
Input clocks for top0 clock controller:
- fin_pll
- dout_sclk_bus0_pll
- dout_sclk_bus1_pll
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
- dout_sclk_aud_pll
Input clocks for top1 clock controller:
- fin_pll
- dout_sclk_bus0_pll
- dout_sclk_bus1_pll
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
Input clocks for ccore clock controller:
- fin_pll
- dout_aclk_ccore_133
Input clocks for peric0 clock controller:
- fin_pll
- dout_aclk_peric0_66
- sclk_uart0
Input clocks for peric1 clock controller:
- fin_pll
- dout_aclk_peric1_66
- sclk_uart1
- sclk_uart2
- sclk_uart3
- sclk_spi0
- sclk_spi1
- sclk_spi2
- sclk_spi3
- sclk_spi4
- sclk_i2s1
- sclk_pcm1
- sclk_spdif
Input clocks for peris clock controller:
- fin_pll
- dout_aclk_peris_66
Input clocks for fsys0 clock controller:
- fin_pll
- dout_aclk_fsys0_200
- dout_sclk_mmc2
Input clocks for fsys1 clock controller:
- fin_pll
- dout_aclk_fsys1_200
- dout_sclk_mmc0
- dout_sclk_mmc1
Input clocks for aud clock controller:
- fin_pll
- fout_aud_pll
......@@ -55,11 +55,4 @@ examples:
<0 72 IRQ_TYPE_LEVEL_HIGH>;
#clock-cells = <1>;
};
can@53fc8000 {
compatible = "fsl,imx53-flexcan", "fsl,imx25-flexcan";
reg = <0x53fc8000 0x4000>;
interrupts = <82>;
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>;
clock-names = "ipg", "per";
};
...
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,exynos5410-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos5410 SoC clock controller
maintainers:
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
- Tomasz Figa <tomasz.figa@gmail.com>
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
name::
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
include/dt-bindings/clock/exynos5410.h header.
properties:
compatible:
oneOf:
- enum:
- samsung,exynos5410-clock
clocks:
description:
Should contain an entry specifying the root clock from external
oscillator supplied through XXTI or XusbXTI pin. This clock should be
defined using standard clock bindings with "fin_pll" clock-output-name.
That clock is being passed internally to the 9 PLLs.
maxItems: 1
"#clock-cells":
const: 1
reg:
maxItems: 1
required:
- compatible
- "#clock-cells"
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/exynos5410.h>
fin_pll: osc-clock {
compatible = "fixed-clock";
clock-frequency = <24000000>;
clock-output-names = "fin_pll";
#clock-cells = <0>;
};
clock-controller@10010000 {
compatible = "samsung,exynos5410-clock";
reg = <0x10010000 0x30000>;
#clock-cells = <1>;
clocks = <&fin_pll>;
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,exynos7-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos7 SoC clock controller
maintainers:
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
- Tomasz Figa <tomasz.figa@gmail.com>
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
name::
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
include/dt-bindings/clock/exynos7-clk.h header.
properties:
compatible:
enum:
- samsung,exynos7-clock-topc
- samsung,exynos7-clock-top0
- samsung,exynos7-clock-top1
- samsung,exynos7-clock-ccore
- samsung,exynos7-clock-peric0
- samsung,exynos7-clock-peric1
- samsung,exynos7-clock-peris
- samsung,exynos7-clock-fsys0
- samsung,exynos7-clock-fsys1
- samsung,exynos7-clock-mscl
- samsung,exynos7-clock-aud
clocks:
minItems: 1
maxItems: 13
clock-names:
minItems: 1
maxItems: 13
"#clock-cells":
const: 1
reg:
maxItems: 1
required:
- compatible
- "#clock-cells"
- reg
allOf:
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-top0
then:
properties:
clocks:
minItems: 6
maxItems: 6
clock-names:
items:
- const: fin_pll
- const: dout_sclk_bus0_pll
- const: dout_sclk_bus1_pll
- const: dout_sclk_cc_pll
- const: dout_sclk_mfc_pll
- const: dout_sclk_aud_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-top1
then:
properties:
clocks:
minItems: 5
maxItems: 5
clock-names:
items:
- const: fin_pll
- const: dout_sclk_bus0_pll
- const: dout_sclk_bus1_pll
- const: dout_sclk_cc_pll
- const: dout_sclk_mfc_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-ccore
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: fin_pll
- const: dout_aclk_ccore_133
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-peric0
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: fin_pll
- const: dout_aclk_peric0_66
- const: sclk_uart0
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-peric1
then:
properties:
clocks:
minItems: 13
maxItems: 13
clock-names:
items:
- const: fin_pll
- const: dout_aclk_peric1_66
- const: sclk_uart1
- const: sclk_uart2
- const: sclk_uart3
- const: sclk_spi0
- const: sclk_spi1
- const: sclk_spi2
- const: sclk_spi3
- const: sclk_spi4
- const: sclk_i2s1
- const: sclk_pcm1
- const: sclk_spdif
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-peris
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: fin_pll
- const: dout_aclk_peris_66
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-fsys0
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: fin_pll
- const: dout_aclk_fsys0_200
- const: dout_sclk_mmc2
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-fsys1
then:
properties:
clocks:
minItems: 7
maxItems: 7
clock-names:
items:
- const: fin_pll
- const: dout_aclk_fsys1_200
- const: dout_sclk_mmc0
- const: dout_sclk_mmc1
- const: dout_sclk_ufsunipro20
- const: dout_sclk_phy_fsys1
- const: dout_sclk_phy_fsys1_26m
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-aud
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: fin_pll
- const: fout_aud_pll
required:
- clock-names
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/exynos7-clk.h>
fin_pll: clock {
compatible = "fixed-clock";
clock-output-names = "fin_pll";
#clock-cells = <0>;
clock-frequency = <24000000>;
};
clock-controller@105e0000 {
compatible = "samsung,exynos7-clock-top1";
reg = <0x105e0000 0xb000>;
#clock-cells = <1>;
clocks = <&fin_pll>,
<&clock_topc DOUT_SCLK_BUS0_PLL>,
<&clock_topc DOUT_SCLK_BUS1_PLL>,
<&clock_topc DOUT_SCLK_CC_PLL>,
<&clock_topc DOUT_SCLK_MFC_PLL>;
clock-names = "fin_pll",
"dout_sclk_bus0_pll",
"dout_sclk_bus1_pll",
"dout_sclk_cc_pll",
"dout_sclk_mfc_pll";
};
* Samsung S5P6442/S5PC110/S5PV210 Clock Controller
Samsung S5P6442, S5PC110 and S5PV210 SoCs contain integrated clock
controller, which generates and supplies clock to various controllers
within the SoC.
Required Properties:
- compatible: should be one of following:
- "samsung,s5pv210-clock" : for clock controller of Samsung
S5PC110/S5PV210 SoCs,
- "samsung,s5p6442-clock" : for clock controller of Samsung
S5P6442 SoC.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/s5pv210.h header and can be used in device tree sources.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xxti": external crystal oscillator connected to XXTI and XXTO pins of
the SoC,
- "xusbxti": external crystal oscillator connected to XUSBXTI and XUSBXTO
pins of the SoC,
A subset of above clocks available on given board shall be specified in
board device tree, including the system base clock, as selected by XOM[0]
pin of the SoC. Refer to generic fixed rate clock bindings
documentation[1] for more information how to specify these clocks.
[1] Documentation/devicetree/bindings/clock/fixed-clock.yaml
Example: Clock controller node:
clock: clock-controller@7e00f000 {
compatible = "samsung,s5pv210-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
};
Example: Required external clocks:
xxti: clock-xxti {
compatible = "fixed-clock";
clock-output-names = "xxti";
clock-frequency = <24000000>;
#clock-cells = <0>;
};
xusbxti: clock-xusbxti {
compatible = "fixed-clock";
clock-output-names = "xusbxti";
clock-frequency = <24000000>;
#clock-cells = <0>;
};
Example: UART controller node that consumes the clock generated by the clock
controller (refer to the standard clock bindings for information about
"clocks" and "clock-names" properties):
uart0: serial@e2900000 {
compatible = "samsung,s5pv210-uart";
reg = <0xe2900000 0x400>;
interrupt-parent = <&vic1>;
interrupts = <10>;
clock-names = "uart", "clk_uart_baud0",
"clk_uart_baud1";
clocks = <&clocks UART0>, <&clocks UART0>,
<&clocks SCLK_UART0>;
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,s5pv210-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S5P6442/S5PC110/S5PV210 SoC clock controller
maintainers:
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
- Tomasz Figa <tomasz.figa@gmail.com>
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
name::
- "xxti" - external crystal oscillator connected to XXTI and XXTO pins of
the SoC,
- "xusbxti" - external crystal oscillator connected to XUSBXTI and XUSBXTO
pins of the SoC,
All available clocks are defined as preprocessor macros in
include/dt-bindings/clock/s5pv210.h header.
properties:
compatible:
enum:
- samsung,s5pv210-clock
- samsung,s5p6442-clock
clocks:
items:
- description: xxti clock
- description: xusbxti clock
clock-names:
items:
- const: xxti
- const: xusbxti
"#clock-cells":
const: 1
reg:
maxItems: 1
required:
- compatible
- "#clock-cells"
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/s5pv210.h>
xxti: clock-0 {
compatible = "fixed-clock";
clock-frequency = <0>;
clock-output-names = "xxti";
#clock-cells = <0>;
};
xusbxti: clock-1 {
compatible = "fixed-clock";
clock-frequency = <0>;
clock-output-names = "xusbxti";
#clock-cells = <0>;
};
clock-controller@e0100000 {
compatible = "samsung,s5pv210-clock";
reg = <0xe0100000 0x10000>;
clock-names = "xxti", "xusbxti";
clocks = <&xxti>, <&xusbxti>;
#clock-cells = <1>;
};
Qualcomm MSM pseudo random number generator.
Required properties:
- compatible : should be "qcom,prng" for 8916 etc
: should be "qcom,prng-ee" for 8996 and later using EE
(Execution Environment) slice of prng
- reg : specifies base physical address and size of the registers map
- clocks : phandle to clock-controller plus clock-specifier pair
- clock-names : "core" clocks all registers, FIFO and circuits in PRNG IP block
Example:
rng@f9bff000 {
compatible = "qcom,prng";
reg = <0xf9bff000 0x200>;
clocks = <&clock GCC_PRNG_AHB_CLK>;
clock-names = "core";
};
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/qcom,prng.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Pseudo Random Number Generator
maintainers:
- Vinod Koul <vkoul@kernel.org>
properties:
compatible:
enum:
- qcom,prng # 8916 etc.
- qcom,prng-ee # 8996 and later using EE
reg:
maxItems: 1
clocks:
maxItems: 1
clock-names:
items:
- const: core
required:
- compatible
- reg
- clocks
- clock-names
additionalProperties: false
examples:
- |
rng@f9bff000 {
compatible = "qcom,prng";
reg = <0xf9bff000 0x200>;
clocks = <&clk 125>;
clock-names = "core";
};
......@@ -31,13 +31,11 @@ properties:
clocks:
items:
- description: Display AHB clock from gcc
- description: Display AXI clock
- description: Display core clock
clock-names:
items:
- const: iface
- const: bus
- const: core
interrupts:
......@@ -160,9 +158,8 @@ examples:
power-domains = <&dispcc MDSS_GDSC>;
clocks = <&gcc GCC_DISP_AHB_CLK>,
<&gcc GCC_DISP_AXI_CLK>,
<&dispcc DISP_CC_MDSS_MDP_CLK>;
clock-names = "iface", "bus", "core";
clock-names = "iface", "core";
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
......
......@@ -35,6 +35,8 @@ properties:
phandle of the gpio for power ic line
Power IC supply enable, High active
port: true
required:
- compatible
- reg
......
......@@ -34,7 +34,7 @@ properties:
description: phandle of gpio for reset line - This should be 8mA, gpio
can be configured using mux, pinctrl, pinctrl-names (active high)
vddio-supply:
vddi0-supply:
description: phandle of the regulator that provides the supply voltage
Power IC supply
......@@ -75,8 +75,6 @@ examples:
reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
port {
tianma_nt36672a_in_0: endpoint {
remote-endpoint = <&dsi0_out>;
......
......@@ -83,13 +83,25 @@ properties:
format:
description: >
Format of the framebuffer:
* `a1r5g5b5` - 16-bit pixels, d[15]=a, d[14:10]=r, d[9:5]=g, d[4:0]=b
* `a2r10g10b10` - 32-bit pixels, d[31:30]=a, d[29:20]=r, d[19:10]=g, d[9:0]=b
* `a8b8g8r8` - 32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r
* `a8r8g8b8` - 32-bit pixels, d[31:24]=a, d[23:16]=r, d[15:8]=g, d[7:0]=b
* `r5g6b5` - 16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b
* `r5g5b5a1` - 16-bit pixels, d[15:11]=r, d[10:6]=g, d[5:1]=b d[1:0]=a
* `r8g8b8` - 24-bit pixels, d[23:16]=r, d[15:8]=g, d[7:0]=b
* `x1r5g5b5` - 16-bit pixels, d[14:10]=r, d[9:5]=g, d[4:0]=b
* `x2r10g10b10` - 32-bit pixels, d[29:20]=r, d[19:10]=g, d[9:0]=b
* `x8r8g8b8` - 32-bit pixels, d[23:16]=r, d[15:8]=g, d[7:0]=b
enum:
- a1r5g5b5
- a2r10g10b10
- a8b8g8r8
- a8r8g8b8
- r5g6b5
- r5g5b5a1
- r8g8b8
- x1r5g5b5
- x2r10g10b10
- x8r8g8b8
......
......@@ -110,7 +110,7 @@ examples:
};
};
panel-dsi@0 {
panel@0 {
compatible = "orisetech,otm8009a";
reg = <0>;
reset-gpios = <&gpioe 4 GPIO_ACTIVE_LOW>;
......@@ -125,4 +125,3 @@ examples:
};
...
......@@ -50,7 +50,7 @@ examples:
dma@3000000 {
compatible = "sifive,fu540-c000-pdma";
reg = <0x3000000 0x8000>;
interrupts = <23 24 25 26 27 28 29 30>;
interrupts = <23>, <24>, <25>, <26>, <27>, <28>, <29>, <30>;
#dma-cells = <1>;
};
......
Broadcom STB "UPG GIO" GPIO controller
The controller's registers are organized as sets of eight 32-bit
registers with each set controlling a bank of up to 32 pins. A single
interrupt is shared for all of the banks handled by the controller.
Required properties:
- compatible:
Must be "brcm,brcmstb-gpio"
- reg:
Define the base and range of the I/O address space containing
the brcmstb GPIO controller registers
- #gpio-cells:
Should be <2>. The first cell is the pin number (within the controller's
pin space), and the second is used for the following:
bit[0]: polarity (0 for active-high, 1 for active-low)
- gpio-controller:
Specifies that the node is a GPIO controller.
- brcm,gpio-bank-widths:
Number of GPIO lines for each bank. Number of elements must
correspond to number of banks suggested by the 'reg' property.
Optional properties:
- interrupts:
The interrupt shared by all GPIO lines for this controller.
- interrupts-extended:
Alternate form of specifying interrupts and parents that allows for
multiple parents. This takes precedence over 'interrupts' and
'interrupt-parent'. Wakeup-capable GPIO controllers often route their
wakeup interrupt lines through a different interrupt controller than the
primary interrupt line, making this property necessary.
- #interrupt-cells:
Should be <2>. The first cell is the GPIO number, the second should specify
flags. The following subset of flags is supported:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
Valid combinations are 1, 2, 3, 4, 8.
See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- interrupt-controller:
Marks the device node as an interrupt controller
- wakeup-source:
GPIOs for this controller can be used as a wakeup source
Example:
upg_gio: gpio@f040a700 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
gpio-controller;
interrupt-controller;
reg = <0xf040a700 0x80>;
interrupt-parent = <&irq0_intc>;
interrupts = <0x6>;
brcm,gpio-bank-widths = <32 32 32 24>;
};
upg_gio_aon: gpio@f04172c0 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
gpio-controller;
interrupt-controller;
reg = <0xf04172c0 0x40>;
interrupt-parent = <&irq0_aon_intc>;
interrupts = <0x6>;
interrupts-extended = <&irq0_aon_intc 0x6>,
<&aon_pm_l2_intc 0x5>;
wakeup-source;
brcm,gpio-bank-widths = <18 4>;
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/brcm,brcmstb-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom STB "UPG GIO" GPIO controller
description: >
The controller's registers are organized as sets of eight 32-bit
registers with each set controlling a bank of up to 32 pins. A single
interrupt is shared for all of the banks handled by the controller.
maintainers:
- Doug Berger <opendmb@gmail.com>
- Florian Fainelli <f.fainelli@gmail.com>
properties:
compatible:
items:
- enum:
- brcm,bcm7445-gpio
- const: brcm,brcmstb-gpio
reg:
maxItems: 1
description: >
Define the base and range of the I/O address space containing
the brcmstb GPIO controller registers
"#gpio-cells":
const: 2
description: >
The first cell is the pin number (within the controller's
pin space), and the second is used for the following:
bit[0]: polarity (0 for active-high, 1 for active-low)
gpio-controller: true
brcm,gpio-bank-widths:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: >
Number of GPIO lines for each bank. Number of elements must
correspond to number of banks suggested by the 'reg' property.
interrupts:
maxItems: 1
description: >
The interrupt shared by all GPIO lines for this controller.
"#interrupt-cells":
const: 2
description: |
The first cell is the GPIO number, the second should specify
flags. The following subset of flags is supported:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
Valid combinations are 1, 2, 3, 4, 8.
interrupt-controller: true
wakeup-source:
type: boolean
description: >
GPIOs for this controller can be used as a wakeup source
required:
- compatible
- reg
- gpio-controller
- "#gpio-cells"
- "brcm,gpio-bank-widths"
additionalProperties: false
examples:
- |
upg_gio: gpio@f040a700 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
gpio-controller;
interrupt-controller;
reg = <0xf040a700 0x80>;
interrupt-parent = <&irq0_intc>;
interrupts = <0x6>;
brcm,gpio-bank-widths = <32 32 32 24>;
};
upg_gio_aon: gpio@f04172c0 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
gpio-controller;
interrupt-controller;
reg = <0xf04172c0 0x40>;
interrupt-parent = <&irq0_aon_intc>;
interrupts = <0x6>;
wakeup-source;
brcm,gpio-bank-widths = <18 4>;
};
......@@ -43,7 +43,6 @@ required:
- gpio-controller
- interrupt-controller
- "#interrupt-cells"
- interrupt-parent
additionalProperties: false
......
......@@ -19,6 +19,7 @@ properties:
- amlogic,meson-g12a-mali
- mediatek,mt8183-mali
- realtek,rtd1619-mali
- renesas,r9a07g044-mali
- rockchip,px30-mali
- rockchip,rk3568-mali
- const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable
......@@ -27,19 +28,26 @@ properties:
maxItems: 1
interrupts:
minItems: 3
items:
- description: Job interrupt
- description: MMU interrupt
- description: GPU interrupt
- description: Event interrupt
interrupt-names:
minItems: 3
items:
- const: job
- const: mmu
- const: gpu
- const: event
clocks:
maxItems: 1
minItems: 1
maxItems: 3
clock-names: true
mali-supply: true
......@@ -52,7 +60,10 @@ properties:
maxItems: 3
resets:
maxItems: 2
minItems: 1
maxItems: 3
reset-names: true
"#cooling-cells":
const: 2
......@@ -94,6 +105,36 @@ allOf:
then:
required:
- resets
- if:
properties:
compatible:
contains:
const: renesas,r9a07g044-mali
then:
properties:
interrupts:
minItems: 4
interrupt-names:
minItems: 4
clocks:
minItems: 3
clock-names:
items:
- const: gpu
- const: bus
- const: bus_ace
resets:
minItems: 3
reset-names:
items:
- const: rst
- const: axi_rst
- const: ace_rst
required:
- clock-names
- power-domains
- resets
- reset-names
- if:
properties:
compatible:
......
......@@ -63,7 +63,6 @@ examples:
i2c0: i2c-bus@40 {
#address-cells = <1>;
#size-cells = <0>;
#interrupt-cells = <1>;
compatible = "aspeed,ast2500-i2c-bus";
reg = <0x40 0x40>;
clocks = <&syscon ASPEED_CLK_APB>;
......
......@@ -31,7 +31,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
ak8975@c {
compatible = "ak,ak8975";
compatible = "asahi-kasei,ak8975";
reg = <0x0c>;
};
};
......
GPIO-based I2C Bus Mux
This binding describes an I2C bus multiplexer that uses GPIOs to
route the I2C signals.
+-----+ +-----+
| dev | | dev |
+------------+ +-----+ +-----+
| SoC | | |
| | /--------+--------+
| +------+ | +------+ child bus A, on GPIO value set to 0
| | I2C |-|--| Mux |
| +------+ | +--+---+ child bus B, on GPIO value set to 1
| | | \----------+--------+--------+
| +------+ | | | | |
| | GPIO |-|-----+ +-----+ +-----+ +-----+
| +------+ | | dev | | dev | | dev |
+------------+ +-----+ +-----+ +-----+
Required properties:
- compatible: i2c-mux-gpio
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
port is connected to.
- mux-gpios: list of gpios used to control the muxer
* Standard I2C mux properties. See i2c-mux.yaml in this directory.
* I2C child bus nodes. See i2c-mux.yaml in this directory.
Optional properties:
- idle-state: value to set the muxer to when idle. When no value is
given, it defaults to the last value used.
For each i2c child node, an I2C child bus will be created. They will
be numbered based on their order in the device tree.
Whenever an access is made to a device on a child bus, the value set
in the relevant node's reg property will be output using the list of
GPIOs, the first in the list holding the least-significant value.
If an idle state is defined, using the idle-state (optional) property,
whenever an access is not being made to a device on a child bus, the
GPIOs will be set according to the idle value.
If an idle state is not defined, the most recently used value will be
left programmed into hardware whenever no access is being made to a
device on a child bus.
Example:
i2cmux {
compatible = "i2c-mux-gpio";
#address-cells = <1>;
#size-cells = <0>;
mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
i2c-parent = <&i2c1>;
i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
ssd1307: oled@3c {
compatible = "solomon,ssd1307fb-i2c";
reg = <0x3c>;
pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7 1>;
};
};
i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
pca9555: pca9555@20 {
compatible = "nxp,pca9555";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
};
};
};
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-mux-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: GPIO-based I2C Bus Mux
maintainers:
- Wolfram Sang <wsa@kernel.org>
description: |
This binding describes an I2C bus multiplexer that uses GPIOs to route the I2C signals.
+-----+ +-----+
| dev | | dev |
+------------+ +-----+ +-----+
| SoC | | |
| | /--------+--------+
| +------+ | +------+ child bus A, on GPIO value set to 0
| | I2C |-|--| Mux |
| +------+ | +--+---+ child bus B, on GPIO value set to 1
| | | \----------+--------+--------+
| +------+ | | | | |
| | GPIO |-|-----+ +-----+ +-----+ +-----+
| +------+ | | dev | | dev | | dev |
+------------+ +-----+ +-----+ +-----+
For each I2C child node, an I2C child bus will be created. They will be numbered based on their
order in the device tree.
Whenever an access is made to a device on a child bus, the value set in the relevant node's reg
property will be output using the list of GPIOs, the first in the list holding the least-
significant value.
If an idle state is defined, using the idle-state (optional) property, whenever an access is not
being made to a device on a child bus, the GPIOs will be set according to the idle value.
If an idle state is not defined, the most recently used value will be left programmed into
hardware whenever no access is being made to a device on a child bus.
properties:
compatible:
const: i2c-mux-gpio
i2c-parent:
description: phandle of the I2C bus that this multiplexer's master-side port is connected to
$ref: "/schemas/types.yaml#/definitions/phandle"
mux-gpios:
description: list of GPIOs used to control the muxer
minItems: 1
maxItems: 4 # Should be enough
idle-state:
description: Value to set the muxer to when idle. When no value is given, it defaults to the
last value used.
$ref: "/schemas/types.yaml#/definitions/uint32"
allOf:
- $ref: i2c-mux.yaml
unevaluatedProperties: false
required:
- compatible
- i2c-parent
- mux-gpios
examples:
- |
i2cmux {
compatible = "i2c-mux-gpio";
#address-cells = <1>;
#size-cells = <0>;
mux-gpios = <&gpio1 22 0>, <&gpio1 23 0>;
i2c-parent = <&i2c1>;
i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
ssd1307: oled@3c {
compatible = "solomon,ssd1307fb-i2c";
reg = <0x3c>;
pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7 1>;
};
};
i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
pca9555: pca9555@20 {
compatible = "nxp,pca9555";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
};
};
};
Pinctrl-based I2C Bus Mux
This binding describes an I2C bus multiplexer that uses pin multiplexing to
route the I2C signals, and represents the pin multiplexing configuration
using the pinctrl device tree bindings.
+-----+ +-----+
| dev | | dev |
+------------------------+ +-----+ +-----+
| SoC | | |
| /----|------+--------+
| +---+ +------+ | child bus A, on first set of pins
| |I2C|---|Pinmux| |
| +---+ +------+ | child bus B, on second set of pins
| \----|------+--------+--------+
| | | | |
+------------------------+ +-----+ +-----+ +-----+
| dev | | dev | | dev |
+-----+ +-----+ +-----+
Required properties:
- compatible: i2c-mux-pinctrl
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
port is connected to.
Also required are:
* Standard pinctrl properties that specify the pin mux state for each child
bus. See ../pinctrl/pinctrl-bindings.txt.
* Standard I2C mux properties. See i2c-mux.yaml in this directory.
* I2C child bus nodes. See i2c-mux.yaml in this directory.
For each named state defined in the pinctrl-names property, an I2C child bus
will be created. I2C child bus numbers are assigned based on the index into
the pinctrl-names property.
The only exception is that no bus will be created for a state named "idle". If
such a state is defined, it must be the last entry in pinctrl-names. For
example:
pinctrl-names = "ddc", "pta", "idle" -> ddc = bus 0, pta = bus 1
pinctrl-names = "ddc", "idle", "pta" -> Invalid ("idle" not last)
pinctrl-names = "idle", "ddc", "pta" -> Invalid ("idle" not last)
Whenever an access is made to a device on a child bus, the relevant pinctrl
state will be programmed into hardware.
If an idle state is defined, whenever an access is not being made to a device
on a child bus, the idle pinctrl state will be programmed into hardware.
If an idle state is not defined, the most recently used pinctrl state will be
left programmed into hardware whenever no access is being made of a device on
a child bus.
Example:
i2cmux {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
#size-cells = <0>;
i2c-parent = <&i2c1>;
pinctrl-names = "ddc", "pta", "idle";
pinctrl-0 = <&state_i2cmux_ddc>;
pinctrl-1 = <&state_i2cmux_pta>;
pinctrl-2 = <&state_i2cmux_idle>;
i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
eeprom {
compatible = "eeprom";
reg = <0x50>;
};
};
i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
eeprom {
compatible = "eeprom";
reg = <0x50>;
};
};
};
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-mux-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Pinctrl-based I2C Bus Mux
maintainers:
- Wolfram Sang <wsa@kernel.org>
description: |
This binding describes an I2C bus multiplexer that uses pin multiplexing to route the I2C
signals, and represents the pin multiplexing configuration using the pinctrl device tree
bindings.
+-----+ +-----+
| dev | | dev |
+------------------------+ +-----+ +-----+
| SoC | | |
| /----|------+--------+
| +---+ +------+ | child bus A, on first set of pins
| |I2C|---|Pinmux| |
| +---+ +------+ | child bus B, on second set of pins
| \----|------+--------+--------+
| | | | |
+------------------------+ +-----+ +-----+ +-----+
| dev | | dev | | dev |
+-----+ +-----+ +-----+
For each named state defined in the pinctrl-names property, an I2C child bus will be created.
I2C child bus numbers are assigned based on the index into the pinctrl-names property.
The only exception is that no bus will be created for a state named "idle". If such a state is
defined, it must be the last entry in pinctrl-names. For example:
pinctrl-names = "ddc", "pta", "idle" -> ddc = bus 0, pta = bus 1
pinctrl-names = "ddc", "idle", "pta" -> Invalid ("idle" not last)
pinctrl-names = "idle", "ddc", "pta" -> Invalid ("idle" not last)
Whenever an access is made to a device on a child bus, the relevant pinctrl state will be
programmed into hardware.
If an idle state is defined, whenever an access is not being made to a device on a child bus,
the idle pinctrl state will be programmed into hardware.
If an idle state is not defined, the most recently used pinctrl state will be left programmed
into hardware whenever no access is being made of a device on a child bus.
properties:
compatible:
const: i2c-mux-pinctrl
i2c-parent:
$ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the I2C bus that this multiplexer's master-side port is connected
to.
allOf:
- $ref: i2c-mux.yaml
unevaluatedProperties: false
required:
- compatible
- i2c-parent
examples:
- |
i2cmux {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
#size-cells = <0>;
i2c-parent = <&i2c1>;
pinctrl-names = "ddc", "pta", "idle";
pinctrl-0 = <&state_i2cmux_ddc>;
pinctrl-1 = <&state_i2cmux_pta>;
pinctrl-2 = <&state_i2cmux_idle>;
i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
};
};
i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
};
};
};
NVIDIA Tegra186 BPMP I2C controller
In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW
devices, such as the I2C controller for the power management I2C bus. Software
running on other CPUs must perform IPC to the BPMP in order to execute
transactions on that I2C bus. This binding describes an I2C bus that is
accessed in such a fashion.
The BPMP I2C node must be located directly inside the main BPMP node. See
../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding.
This node represents an I2C controller. See ../i2c/i2c.txt for details of the
core I2C binding.
Required properties:
- compatible:
Array of strings.
One of:
- "nvidia,tegra186-bpmp-i2c".
- #address-cells: Address cells for I2C device address.
Single-cell integer.
Must be <1>.
- #size-cells:
Single-cell integer.
Must be <0>.
- nvidia,bpmp-bus-id:
Single-cell integer.
Indicates the I2C bus number this DT node represent, as defined by the
BPMP firmware.
Example:
bpmp {
...
i2c {
compatible = "nvidia,tegra186-bpmp-i2c";
#address-cells = <1>;
#size-cells = <0>;
nvidia,bpmp-bus-id = <5>;
};
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/nvidia,tegra186-bpmp-i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra186 (and later) BPMP I2C controller
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
description: |
In Tegra186 and later, the BPMP (Boot and Power Management Processor)
owns certain HW devices, such as the I2C controller for the power
management I2C bus. Software running on other CPUs must perform IPC to
the BPMP in order to execute transactions on that I2C bus. This
binding describes an I2C bus that is accessed in such a fashion.
The BPMP I2C node must be located directly inside the main BPMP node.
See ../firmware/nvidia,tegra186-bpmp.yaml for details of the BPMP
binding.
This node represents an I2C controller. See ../i2c/i2c.txt for details
of the core I2C binding.
properties:
compatible:
const: nvidia,tegra186-bpmp-i2c
nvidia,bpmp-bus-id:
$ref: /schemas/types.yaml#/definitions/uint32
description: Indicates the I2C bus number this DT node represents,
as defined by the BPMP firmware.
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml
unevaluatedProperties: false
required:
- compatible
- "#address-cells"
- "#size-cells"
- nvidia,bpmp-bus-id
NVIDIA Tegra20/Tegra30/Tegra114 I2C controller driver.
Required properties:
- compatible : For Tegra20, must be one of "nvidia,tegra20-i2c-dvc" or
"nvidia,tegra20-i2c". For Tegra30, must be "nvidia,tegra30-i2c".
For Tegra114, must be "nvidia,tegra114-i2c". Otherwise, must be
"nvidia,<chip>-i2c", plus at least one of the above, where <chip> is
tegra124, tegra132, or tegra210.
Details of compatible are as follows:
nvidia,tegra20-i2c-dvc: Tegra20 has specific I2C controller called as DVC I2C
controller. This only support master mode of I2C communication. Register
interface/offset and interrupts handling are different than generic I2C
controller. Driver of DVC I2C controller is only compatible with
"nvidia,tegra20-i2c-dvc".
nvidia,tegra20-i2c: Tegra20 has 4 generic I2C controller. This can support
master and slave mode of I2C communication. The i2c-tegra driver only
support master mode of I2C communication. Driver of I2C controller is
only compatible with "nvidia,tegra20-i2c".
nvidia,tegra30-i2c: Tegra30 has 5 generic I2C controller. This controller is
very much similar to Tegra20 I2C controller with additional feature:
Continue Transfer Support. This feature helps to implement M_NO_START
as per I2C core API transfer flags. Driver of I2C controller is
compatible with "nvidia,tegra30-i2c" to enable the continue transfer
support. This is also compatible with "nvidia,tegra20-i2c" without
continue transfer support.
nvidia,tegra114-i2c: Tegra114 has 5 generic I2C controller. This controller is
very much similar to Tegra30 I2C controller with some hardware
modification:
- Tegra30/Tegra20 I2C controller has 2 clock source called div-clk and
fast-clk. Tegra114 has only one clock source called as div-clk and
hence clock mechanism is changed in I2C controller.
- Tegra30/Tegra20 I2C controller has enabled per packet transfer by
default and there is no way to disable it. Tegra114 has this
interrupt disable by default and SW need to enable explicitly.
Due to above changes, Tegra114 I2C driver makes incompatible with
previous hardware driver. Hence, tegra114 I2C controller is compatible
with "nvidia,tegra114-i2c".
nvidia,tegra210-i2c-vi: Tegra210 has one I2C controller that is on host1x bus
and is part of VE power domain and typically used for camera use-cases.
This VI I2C controller is mostly compatible with the programming model
of the regular I2C controllers with a few exceptions. The I2C registers
start at an offset of 0xc00 (instead of 0), registers are 16 bytes
apart (rather than 4) and the controller does not support slave mode.
- reg: Should contain I2C controller registers physical address and length.
- interrupts: Should contain I2C controller interrupts.
- address-cells: Address cells for I2C device address.
- size-cells: Size of the I2C device address.
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
Tegra20/Tegra30:
- div-clk
- fast-clk
Tegra114:
- div-clk
Tegra210:
- div-clk
- slow (only for nvidia,tegra210-i2c-vi compatible node)
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- i2c
- power-domains: Only for nvidia,tegra210-i2c-vi compatible node and must
include venc powergate node as vi i2c is part of VE power domain.
tegra210-i2c-vi:
- pd_venc
- dmas: Must contain an entry for each entry in clock-names.
See ../dma/dma.txt for details.
- dma-names: Must include the following entries:
- rx
- tx
Example:
i2c@7000c000 {
compatible = "nvidia,tegra20-i2c";
reg = <0x7000c000 0x100>;
interrupts = <0 38 0x04>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&tegra_car 12>, <&tegra_car 124>;
clock-names = "div-clk", "fast-clk";
resets = <&tegra_car 12>;
reset-names = "i2c";
dmas = <&apbdma 16>, <&apbdma 16>;
dma-names = "rx", "tx";
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/nvidia,tegra20-i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
title: NVIDIA Tegra I2C controller driver
properties:
compatible:
oneOf:
- description: Tegra20 has 4 generic I2C controller. This can support
master and slave mode of I2C communication. The i2c-tegra driver
only support master mode of I2C communication. Driver of I2C
controller is only compatible with "nvidia,tegra20-i2c".
const: nvidia,tegra20-i2c
- description: Tegra20 has specific I2C controller called as DVC I2C
controller. This only support master mode of I2C communication.
Register interface/offset and interrupts handling are different than
generic I2C controller. Driver of DVC I2C controller is only
compatible with "nvidia,tegra20-i2c-dvc".
const: nvidia,tegra20-i2c-dvc
- description: |
Tegra30 has 5 generic I2C controller. This controller is very much
similar to Tegra20 I2C controller with additional feature: Continue
Transfer Support. This feature helps to implement M_NO_START as per
I2C core API transfer flags. Driver of I2C controller is compatible
with "nvidia,tegra30-i2c" to enable the continue transfer support.
This is also compatible with "nvidia,tegra20-i2c" without continue
transfer support.
items:
- const: nvidia,tegra30-i2c
- const: nvidia,tegra20-i2c
- description: |
Tegra114 has 5 generic I2C controllers. This controller is very much
similar to Tegra30 I2C controller with some hardware modification:
- Tegra30/Tegra20 I2C controller has 2 clock source called div-clk
and fast-clk. Tegra114 has only one clock source called as
div-clk and hence clock mechanism is changed in I2C controller.
- Tegra30/Tegra20 I2C controller has enabled per packet transfer
by default and there is no way to disable it. Tegra114 has this
interrupt disable by default and SW need to enable explicitly.
Due to above changes, Tegra114 I2C driver makes incompatible with
previous hardware driver. Hence, Tegra114 I2C controller is
compatible with "nvidia,tegra114-i2c".
const: nvidia,tegra114-i2c
- description: |
Tegra124 has 6 generic I2C controllers. These controllers are very
similar to those found on Tegra114 but also contain several hardware
improvements and new registers.
const: nvidia,tegra124-i2c
- description: |
Tegra210 has 6 generic I2C controllers. These controllers are very
similar to those found on Tegra124.
items:
- const: nvidia,tegra210-i2c
- const: nvidia,tegra124-i2c
- description: |
Tegra210 has one I2C controller that is on host1x bus and is part of
the VE power domain and typically used for camera use-cases. This VI
I2C controller is mostly compatible with the programming model of
the regular I2C controllers with a few exceptions. The I2C registers
start at an offset of 0xc00 (instead of 0), registers are 16 bytes
apart (rather than 4) and the controller does not support slave
mode.
const: nvidia,tegra210-i2c-vi
- description: |
Tegra186 has 9 generic I2C controllers, two of which are in the AON
(always-on) partition of the SoC. All of these controllers are very
similar to those found on Tegra210.
const: nvidia,tegra186-i2c
- description: |
Tegra194 has 8 generic I2C controllers, two of which are in the AON
(always-on) partition of the SoC. All of these controllers are very
similar to those found on Tegra186. However, these controllers have
support for 64 KiB transactions whereas earlier chips supported no
more than 4 KiB per transactions.
const: nvidia,tegra194-i2c
reg:
maxItems: 1
interrupts:
maxItems: 1
'#address-cells':
const: 1
'#size-cells':
const: 0
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
maxItems: 2
resets:
items:
- description: module reset
reset-names:
items:
- const: i2c
dmas:
items:
- description: DMA channel for the reception FIFO
- description: DMA channel for the transmission FIFO
dma-names:
items:
- const: rx
- const: tx
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml
- if:
properties:
compatible:
contains:
enum:
- nvidia,tegra20-i2c
- nvidia,tegra30-i2c
then:
properties:
clock-names:
items:
- const: div-clk
- const: fast-clk
- if:
properties:
compatible:
contains:
const: nvidia,tegra114-i2c
then:
properties:
clock-names:
items:
- const: div-clk
- if:
properties:
compatible:
contains:
const: nvidia,tegra210-i2c
then:
properties:
clock-names:
items:
- const: div-clk
- if:
properties:
compatible:
contains:
const: nvidia,tegra210-i2c-vi
then:
properties:
clock-names:
items:
- const: div-clk
- const: slow
power-domains:
items:
- description: phandle to the VENC power domain
unevaluatedProperties: false
examples:
- |
i2c@7000c000 {
compatible = "nvidia,tegra20-i2c";
reg = <0x7000c000 0x100>;
interrupts = <0 38 0x04>;
clocks = <&tegra_car 12>, <&tegra_car 124>;
clock-names = "div-clk", "fast-clk";
resets = <&tegra_car 12>;
reset-names = "i2c";
dmas = <&apbdma 16>, <&apbdma 16>;
dma-names = "rx", "tx";
#address-cells = <1>;
#size-cells = <0>;
};
......@@ -112,6 +112,9 @@ examples:
clocks = <&rcc 0 149>;
};
- |
#include <dt-bindings/mfd/stm32f7-rcc.h>
#include <dt-bindings/clock/stm32fx-clock.h>
//Example 2 (with st,stm32f7-i2c compatible)
i2c@40005800 {
compatible = "st,stm32f7-i2c";
......@@ -124,6 +127,9 @@ examples:
clocks = <&rcc 1 CLK_I2C1>;
};
- |
#include <dt-bindings/mfd/stm32f7-rcc.h>
#include <dt-bindings/clock/stm32fx-clock.h>
//Example 3 (with st,stm32mp15-i2c compatible on stm32mp)
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
......
......@@ -61,7 +61,7 @@ examples:
#size-cells = <0>;
magnetometer@c {
compatible = "ak,ak8975";
compatible = "asahi-kasei,ak8975";
reg = <0x0c>;
};
};
......
......@@ -95,7 +95,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
magnetometer@c {
compatible = "ak,ak8975";
compatible = "asahi-kasei,ak8975";
reg = <0x0c>;
};
};
......
......@@ -96,7 +96,7 @@ examples:
vdd-supply = <&ldo1_reg>;
iovdd-supply = <&ldo2_reg>;
reset-gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
interrupts = <&gpio6 13 IRQ_TYPE_EDGE_RISING>;
interrupts = <13 IRQ_TYPE_EDGE_RISING>;
};
};
......
......@@ -448,17 +448,17 @@ examples:
reg = <20>;
adi,sensor-type = <9>; //custom thermocouple
adi,single-ended;
adi,custom-thermocouple = /bits/ 64
<(-50220000) 0>,
<(-30200000) 99100000>,
<(-5300000) 135400000>,
<0 273150000>,
<40200000 361200000>,
<55300000 522100000>,
<88300000 720300000>,
<132200000 811200000>,
<188700000 922500000>,
<460400000 1000000000>; //10 pairs
adi,custom-thermocouple =
/bits/ 64 <(-50220000) 0>,
/bits/ 64 <(-30200000) 99100000>,
/bits/ 64 <(-5300000) 135400000>,
/bits/ 64 <0 273150000>,
/bits/ 64 <40200000 361200000>,
/bits/ 64 <55300000 522100000>,
/bits/ 64 <88300000 720300000>,
/bits/ 64 <132200000 811200000>,
/bits/ 64 <188700000 922500000>,
/bits/ 64 <460400000 1000000000>; //10 pairs
};
};
......
* PWM vibrator device tree bindings
Registers a PWM device as vibrator. It is expected, that the vibrator's
strength increases based on the duty cycle of the enable PWM channel
(100% duty cycle meaning strongest vibration, 0% meaning no vibration).
The binding supports an optional direction PWM channel, that can be
driven at fixed duty cycle. If available this is can be used to increase
the vibration effect of some devices.
Required properties:
- compatible: should contain "pwm-vibrator"
- pwm-names: Should contain "enable" and optionally "direction"
- pwms: Should contain a PWM handle for each entry in pwm-names
Optional properties:
- vcc-supply: Phandle for the regulator supplying power
- direction-duty-cycle-ns: Duty cycle of the direction PWM channel in
nanoseconds, defaults to 50% of the channel's
period.
Example from Motorola Droid 4:
&omap4_pmx_core {
vibrator_direction_pin: pinmux_vibrator_direction_pin {
pinctrl-single,pins = <
OMAP4_IOPAD(0x1ce, PIN_OUTPUT | MUX_MODE1) /* dmtimer8_pwm_evt (gpio_27) */
>;
};
vibrator_enable_pin: pinmux_vibrator_enable_pin {
pinctrl-single,pins = <
OMAP4_IOPAD(0X1d0, PIN_OUTPUT | MUX_MODE1) /* dmtimer9_pwm_evt (gpio_28) */
>;
};
};
/ {
pwm8: dmtimer-pwm {
pinctrl-names = "default";
pinctrl-0 = <&vibrator_direction_pin>;
compatible = "ti,omap-dmtimer-pwm";
#pwm-cells = <3>;
ti,timers = <&timer8>;
ti,clock-source = <0x01>;
};
pwm9: dmtimer-pwm {
pinctrl-names = "default";
pinctrl-0 = <&vibrator_enable_pin>;
compatible = "ti,omap-dmtimer-pwm";
#pwm-cells = <3>;
ti,timers = <&timer9>;
ti,clock-source = <0x01>;
};
vibrator {
compatible = "pwm-vibrator";
pwms = <&pwm9 0 1000000000 0>,
<&pwm8 0 1000000000 0>;
pwm-names = "enable", "direction";
direction-duty-cycle-ns = <1000000000>;
};
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/input/pwm-vibrator.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: PWM vibrator
maintainers:
- Sebastian Reichel <sre@kernel.org>
description: >
Registers a PWM device as vibrator. It is expected, that the vibrator's
strength increases based on the duty cycle of the enable PWM channel
(100% duty cycle meaning strongest vibration, 0% meaning no vibration).
The binding supports an optional direction PWM channel, that can be
driven at fixed duty cycle. If available this is can be used to increase
the vibration effect of some devices.
properties:
compatible:
const: pwm-vibrator
pwm-names:
items:
- const: enable
- const: direction
minItems: 1
pwms:
minItems: 1
maxItems: 2
vcc-supply: true
direction-duty-cycle-ns:
description: >
Duty cycle of the direction PWM channel in nanoseconds,
defaults to 50% of the channel's period.
required:
- compatible
- pwm-names
- pwms
additionalProperties: false
examples:
- |
vibrator {
compatible = "pwm-vibrator";
pwms = <&pwm9 0 1000000000 0>,
<&pwm8 0 1000000000 0>;
pwm-names = "enable", "direction";
direction-duty-cycle-ns = <1000000000>;
};
......@@ -239,6 +239,7 @@ examples:
};
};
- |
interrupt-controller@2c010000 {
compatible = "arm,gic-v3";
#interrupt-cells = <4>;
......@@ -254,7 +255,7 @@ examples:
<0x2c040000 0x2000>, // GICC
<0x2c060000 0x2000>, // GICH
<0x2c080000 0x2000>; // GICV
interrupts = <1 9 4>;
interrupts = <1 9 4 0>;
msi-controller@2c200000 {
compatible = "arm,gic-v3-its";
......
Broadcom BCM3380-style Level 1 / Level 2 interrupt controller
This interrupt controller shows up in various forms on many BCM338x/BCM63xx
chipsets. It has the following properties:
- outputs a single interrupt signal to its interrupt controller parent
- contains one or more enable/status word pairs, which often appear at
different offsets in different blocks
- no atomic set/clear operations
Required properties:
- compatible: should be "brcm,bcm3380-l2-intc"
- reg: specifies one or more enable/status pairs, in the following format:
<enable_reg 0x4 status_reg 0x4>...
- interrupt-controller: identifies the node as an interrupt controller
- #interrupt-cells: specifies the number of cells needed to encode an interrupt
source, should be 1.
- interrupts: specifies the interrupt line in the interrupt-parent controller
node, valid values depend on the type of parent interrupt controller
Optional properties:
- brcm,irq-can-wake: if present, this means the L2 controller can be used as a
wakeup source for system suspend/resume.
Example:
irq0_intc: interrupt-controller@10000020 {
compatible = "brcm,bcm3380-l2-intc";
reg = <0x10000024 0x4 0x1000002c 0x4>,
<0x10000020 0x4 0x10000028 0x4>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&cpu_intc>;
interrupts = <2>;
};
Broadcom BCM7038-style Level 1 interrupt controller
This block is a first level interrupt controller that is typically connected
directly to one of the HW INT lines on each CPU. Every BCM7xxx set-top chip
since BCM7038 has contained this hardware.
Key elements of the hardware design include:
- 64, 96, 128, or 160 incoming level IRQ lines
- Most onchip peripherals are wired directly to an L1 input
- A separate instance of the register set for each CPU, allowing individual
peripheral IRQs to be routed to any CPU
- Atomic mask/unmask operations
- No polarity/level/edge settings
- No FIFO or priority encoder logic; software is expected to read all
2-5 status words to determine which IRQs are pending
Required properties:
- compatible: should be "brcm,bcm7038-l1-intc"
- reg: specifies the base physical address and size of the registers;
the number of supported IRQs is inferred from the size argument
- interrupt-controller: identifies the node as an interrupt controller
- #interrupt-cells: specifies the number of cells needed to encode an interrupt
source, should be 1.
- interrupts: specifies the interrupt line(s) in the interrupt-parent controller
node; valid values depend on the type of parent interrupt controller
Optional properties:
- brcm,irq-can-wake: If present, this means the L1 controller can be used as a
wakeup source for system suspend/resume.
Optional properties:
- brcm,int-fwd-mask: if present, a bit mask to indicate which interrupts
have already been configured by the firmware and should be left unmanaged.
This should have one 32-bit word per status/set/clear/mask group.
If multiple reg ranges and interrupt-parent entries are present on an SMP
system, the driver will allow IRQ SMP affinity to be set up through the
/proc/irq/ interface. In the simplest possible configuration, only one
reg range and one interrupt-parent is needed.
Example:
periph_intc: periph_intc@1041a400 {
compatible = "brcm,bcm7038-l1-intc";
reg = <0x1041a400 0x30 0x1041a600 0x30>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&cpu_intc>;
interrupts = <2>, <3>;
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/brcm,bcm7038-l1-intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM7038-style Level 1 interrupt controller
description: >
This block is a first level interrupt controller that is typically connected
directly to one of the HW INT lines on each CPU. Every BCM7xxx set-top chip
since BCM7038 has contained this hardware.
Key elements of the hardware design include:
- 64, 96, 128, or 160 incoming level IRQ lines
- Most onchip peripherals are wired directly to an L1 input
- A separate instance of the register set for each CPU, allowing individual
peripheral IRQs to be routed to any CPU
- Atomic mask/unmask operations
- No polarity/level/edge settings
- No FIFO or priority encoder logic; software is expected to read all
2-5 status words to determine which IRQs are pending
If multiple reg ranges and interrupt-parent entries are present on an SMP
system, the driver will allow IRQ SMP affinity to be set up through the
/proc/irq/ interface. In the simplest possible configuration, only one
reg range and one interrupt-parent is needed.
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
allOf:
- $ref: /schemas/interrupt-controller.yaml#
properties:
compatible:
const: brcm,bcm7038-l1-intc
reg:
description: >
Specifies the base physical address and size of the registers
the number of supported IRQs is inferred from the size argument
interrupt-controller: true
"#interrupt-cells":
const: 1
interrupts:
description: >
Specifies the interrupt line(s) in the interrupt-parent controller node;
valid values depend on the type of parent interrupt controller
brcm,irq-can-wake:
type: boolean
description: >
If present, this means the L1 controller can be used as a
wakeup source for system suspend/resume.
brcm,int-fwd-mask:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
If present, a bit mask to indicate which interrupts have already been
configured by the firmware and should be left unmanaged. This should
have one 32-bit word per status/set/clear/mask group.
required:
- compatible
- reg
- interrupt-controller
- "#interrupt-cells"
- interrupts
additionalProperties: false
examples:
- |
periph_intc: interrupt-controller@1041a400 {
compatible = "brcm,bcm7038-l1-intc";
reg = <0x1041a400 0x30>, <0x1041a600 0x30>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&cpu_intc>;
interrupts = <2>, <3>;
};
Broadcom BCM7120-style Level 2 interrupt controller
This interrupt controller hardware is a second level interrupt controller that
is hooked to a parent interrupt controller: e.g: ARM GIC for ARM-based
platforms. It can be found on BCM7xxx products starting with BCM7120.
Such an interrupt controller has the following hardware design:
- outputs multiple interrupts signals towards its interrupt controller parent
- controls how some of the interrupts will be flowing, whether they will
directly output an interrupt signal towards the interrupt controller parent,
or if they will output an interrupt signal at this 2nd level interrupt
controller, in particular for UARTs
- has one 32-bit enable word and one 32-bit status word
- no atomic set/clear operations
- not all bits within the interrupt controller actually map to an interrupt
The typical hardware layout for this controller is represented below:
2nd level interrupt line Outputs for the parent controller (e.g: ARM GIC)
0 -----[ MUX ] ------------|==========> GIC interrupt 75
\-----------\
|
1 -----[ MUX ] --------)---|==========> GIC interrupt 76
\------------|
|
2 -----[ MUX ] --------)---|==========> GIC interrupt 77
\------------|
|
3 ---------------------|
4 ---------------------|
5 ---------------------|
7 ---------------------|---|===========> GIC interrupt 66
9 ---------------------|
10 --------------------|
11 --------------------/
6 ------------------------\
|===========> GIC interrupt 64
8 ------------------------/
12 ........................ X
13 ........................ X (not connected)
..
31 ........................ X
Required properties:
- compatible: should be "brcm,bcm7120-l2-intc"
- reg: specifies the base physical address and size of the registers
- interrupt-controller: identifies the node as an interrupt controller
- #interrupt-cells: specifies the number of cells needed to encode an interrupt
source, should be 1.
- interrupts: specifies the interrupt line(s) in the interrupt-parent controller
node, valid values depend on the type of parent interrupt controller
- brcm,int-map-mask: 32-bits bit mask describing how many and which interrupts
are wired to this 2nd level interrupt controller, and how they match their
respective interrupt parents. Should match exactly the number of interrupts
specified in the 'interrupts' property.
Optional properties:
- brcm,irq-can-wake: if present, this means the L2 controller can be used as a
wakeup source for system suspend/resume.
- brcm,int-fwd-mask: if present, a bit mask to configure the interrupts which
have a mux gate, typically UARTs. Setting these bits will make their
respective interrupt outputs bypass this 2nd level interrupt controller
completely; it is completely transparent for the interrupt controller
parent. This should have one 32-bit word per enable/status pair.
Example:
irq0_intc: interrupt-controller@f0406800 {
compatible = "brcm,bcm7120-l2-intc";
interrupt-parent = <&intc>;
#interrupt-cells = <1>;
reg = <0xf0406800 0x8>;
interrupt-controller;
interrupts = <0x0 0x42 0x0>, <0x0 0x40 0x0>;
brcm,int-map-mask = <0xeb8>, <0x140>;
brcm,int-fwd-mask = <0x7>;
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/brcm,bcm7120-l2-intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM7120-style Level 2 and Broadcom BCM3380 Level 1 / Level 2
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
description: >
This interrupt controller hardware is a second level interrupt controller that
is hooked to a parent interrupt controller: e.g: ARM GIC for ARM-based
platforms. It can be found on BCM7xxx products starting with BCM7120.
Such an interrupt controller has the following hardware design:
- outputs multiple interrupts signals towards its interrupt controller parent
- controls how some of the interrupts will be flowing, whether they will
directly output an interrupt signal towards the interrupt controller parent,
or if they will output an interrupt signal at this 2nd level interrupt
controller, in particular for UARTs
- has one 32-bit enable word and one 32-bit status word
- no atomic set/clear operations
- not all bits within the interrupt controller actually map to an interrupt
The typical hardware layout for this controller is represented below:
2nd level interrupt line Outputs for the parent controller (e.g: ARM GIC)
0 -----[ MUX ] ------------|==========> GIC interrupt 75
\-----------\
|
1 -----[ MUX ] --------)---|==========> GIC interrupt 76
\------------|
|
2 -----[ MUX ] --------)---|==========> GIC interrupt 77
\------------|
|
3 ---------------------|
4 ---------------------|
5 ---------------------|
7 ---------------------|---|===========> GIC interrupt 66
9 ---------------------|
10 --------------------|
11 --------------------/
6 ------------------------\
|===========> GIC interrupt 64
8 ------------------------/
12 ........................ X
13 ........................ X (not connected)
..
31 ........................ X
The BCM3380 Level 1 / Level 2 interrrupt controller shows up in various forms
on many BCM338x/BCM63xx chipsets. It has the following properties:
- outputs a single interrupt signal to its interrupt controller parent
- contains one or more enable/status word pairs, which often appear at
different offsets in different blocks
- no atomic set/clear operations
allOf:
- $ref: /schemas/interrupt-controller.yaml#
properties:
compatible:
items:
- enum:
- brcm,bcm7120-l2-intc
- brcm,bcm3380-l2-intc
reg:
minItems: 1
maxItems: 4
description: >
Specifies the base physical address and size of the registers
interrupt-controller: true
"#interrupt-cells":
const: 1
interrupts:
minItems: 1
maxItems: 32
brcm,int-map-mask:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: >
32-bits bit mask describing how many and which interrupts are wired to
this 2nd level interrupt controller, and how they match their respective
interrupt parents. Should match exactly the number of interrupts
specified in the 'interrupts' property.
brcm,irq-can-wake:
type: boolean
description: >
If present, this means the L2 controller can be used as a wakeup source
for system suspend/resume.
brcm,int-fwd-mask:
$ref: /schemas/types.yaml#/definitions/uint32
description: >
if present, a bit mask to configure the interrupts which have a mux gate,
typically UARTs. Setting these bits will make their respective interrupt
outputs bypass this 2nd level interrupt controller completely; it is
completely transparent for the interrupt controller parent. This should
have one 32-bit word per enable/status pair.
additionalProperties: false
required:
- compatible
- reg
- interrupt-controller
- "#interrupt-cells"
- interrupts
examples:
- |
irq0_intc: interrupt-controller@f0406800 {
compatible = "brcm,bcm7120-l2-intc";
interrupt-parent = <&intc>;
#interrupt-cells = <1>;
reg = <0xf0406800 0x8>;
interrupt-controller;
interrupts = <0x0 0x42 0x0>, <0x0 0x40 0x0>;
brcm,int-map-mask = <0xeb8>, <0x140>;
brcm,int-fwd-mask = <0x7>;
};
- |
irq1_intc: interrupt-controller@10000020 {
compatible = "brcm,bcm3380-l2-intc";
reg = <0x10000024 0x4>, <0x1000002c 0x4>,
<0x10000020 0x4>, <0x10000028 0x4>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&cpu_intc>;
interrupts = <2>;
};
Broadcom Generic Level 2 Interrupt Controller
Required properties:
- compatible: should be one of:
"brcm,hif-spi-l2-intc" or
"brcm,upg-aux-aon-l2-intc" or
"brcm,l2-intc" for latched interrupt controllers
should be "brcm,bcm7271-l2-intc" for level interrupt controllers
- reg: specifies the base physical address and size of the registers
- interrupt-controller: identifies the node as an interrupt controller
- #interrupt-cells: specifies the number of cells needed to encode an
interrupt source. Should be 1.
- interrupts: specifies the interrupt line in the interrupt-parent irq space
to be used for cascading
Optional properties:
- brcm,irq-can-wake: If present, this means the L2 controller can be used as a
wakeup source for system suspend/resume.
Example:
hif_intr2_intc: interrupt-controller@f0441000 {
compatible = "brcm,l2-intc";
reg = <0xf0441000 0x30>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&intc>;
interrupts = <0x0 0x20 0x0>;
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/brcm,l2-intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Generic Level 2 Interrupt Controller
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
allOf:
- $ref: /schemas/interrupt-controller.yaml#
properties:
compatible:
oneOf:
- items:
- enum:
- brcm,hif-spi-l2-intc
- brcm,upg-aux-aon-l2-intc
- const: brcm,l2-intc
- items:
- enum:
- brcm,bcm2711-l2-intc
- const: brcm,l2-intc
- items:
- const: brcm,bcm7271-l2-intc
- items:
- const: brcm,l2-intc
reg:
maxItems: 1
description: >
Specifies the base physical address and size of the registers
interrupt-controller: true
"#interrupt-cells":
const: 1
interrupts:
maxItems: 1
interrupt-names:
maxItems: 1
brcm,irq-can-wake:
type: boolean
description: >
If present, this means the L2 controller can be used as a wakeup source
for system suspend/resume.
additionalProperties: false
required:
- compatible
- reg
- interrupt-controller
- "#interrupt-cells"
- interrupts
examples:
- |
hif_intr2_intc: interrupt-controller@f0441000 {
compatible = "brcm,l2-intc";
reg = <0xf0441000 0x30>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&intc>;
interrupts = <0x0 0x20 0x0>;
};
LEDs connected to Broadcom BCM6328 controller
This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268.
In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
However, on some devices there are Serial LEDs (LEDs connected to a 74x164
controller), which can either be controlled by software (exporting the 74x164
as spi-gpio. See Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml),
or by hardware using this driver.
Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and
exporting the 74x164 as spi-gpio prevents those LEDs to be hardware
controlled, so the only chance to keep them working is by using this driver.
BCM6328 LED controller has a HWDIS register, which controls whether a LED
should be controlled by a hardware signal instead of the MODE register value,
with 0 meaning hardware control enabled and 1 hardware control disabled. This
is usually 1:1 for hardware to LED signals, but through the activity/link
registers you have some limited control over rerouting the LEDs (as
explained later in brcm,link-signal-sources). Even if a LED is hardware
controlled you are still able to make it blink or light it up if it isn't,
but you can't turn it off if the hardware decides to light it up. For this
reason, hardware controlled LEDs aren't registered as LED class devices.
Required properties:
- compatible : should be "brcm,bcm6328-leds".
- #address-cells : must be 1.
- #size-cells : must be 0.
- reg : BCM6328 LED controller address and size.
Optional properties:
- brcm,serial-leds : Boolean, enables Serial LEDs.
Default : false
- brcm,serial-mux : Boolean, enables Serial LEDs multiplexing.
Default : false
- brcm,serial-clk-low : Boolean, makes clock signal active low.
Default : false
- brcm,serial-dat-low : Boolean, makes data signal active low.
Default : false
- brcm,serial-shift-inv : Boolean, inverts Serial LEDs shift direction.
Default : false
Each LED is represented as a sub-node of the brcm,bcm6328-leds device.
LED sub-node required properties:
- reg : LED pin number (only LEDs 0 to 23 are valid).
LED sub-node optional properties:
a) Optional properties for sub-nodes related to software controlled LEDs:
- label : see Documentation/devicetree/bindings/leds/common.txt
- active-low : Boolean, makes LED active low.
Default : false
- default-state : see
Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : see
Documentation/devicetree/bindings/leds/common.txt
b) Optional properties for sub-nodes related to hardware controlled LEDs:
- brcm,hardware-controlled : Boolean, makes this LED hardware controlled.
Default : false
- brcm,link-signal-sources : An array of hardware link
signal sources. Up to four link hardware signals can get muxed into
these LEDs. Only valid for LEDs 0 to 7, where LED signals 0 to 3 may
be muxed to LEDs 0 to 3, and signals 4 to 7 may be muxed to LEDs
4 to 7. A signal can be muxed to more than one LED, and one LED can
have more than one source signal.
- brcm,activity-signal-sources : An array of hardware activity
signal sources. Up to four activity hardware signals can get muxed into
these LEDs. Only valid for LEDs 0 to 7, where LED signals 0 to 3 may
be muxed to LEDs 0 to 3, and signals 4 to 7 may be muxed to LEDs
4 to 7. A signal can be muxed to more than one LED, and one LED can
have more than one source signal.
Examples:
Scenario 1 : BCM6328 with 4 EPHY LEDs
leds0: led-controller@10000800 {
compatible = "brcm,bcm6328-leds";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x10000800 0x24>;
alarm_red@2 {
reg = <2>;
active-low;
label = "red:alarm";
};
inet_green@3 {
reg = <3>;
active-low;
label = "green:inet";
};
power_green@4 {
reg = <4>;
active-low;
label = "green:power";
default-state = "on";
};
ephy0_spd@17 {
reg = <17>;
brcm,hardware-controlled;
};
ephy1_spd@18 {
reg = <18>;
brcm,hardware-controlled;
};
ephy2_spd@19 {
reg = <19>;
brcm,hardware-controlled;
};
ephy3_spd@20 {
reg = <20>;
brcm,hardware-controlled;
};
};
Scenario 2 : BCM63268 with Serial/GPHY0 LEDs
leds0: led-controller@10001900 {
compatible = "brcm,bcm6328-leds";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x10001900 0x24>;
brcm,serial-leds;
brcm,serial-dat-low;
brcm,serial-shift-inv;
gphy0_spd0@0 {
reg = <0>;
brcm,hardware-controlled;
brcm,link-signal-sources = <0>;
};
gphy0_spd1@1 {
reg = <1>;
brcm,hardware-controlled;
brcm,link-signal-sources = <1>;
};
inet_red@2 {
reg = <2>;
active-low;
label = "red:inet";
};
dsl_green@3 {
reg = <3>;
active-low;
label = "green:dsl";
};
usb_green@4 {
reg = <4>;
active-low;
label = "green:usb";
};
wps_green@7 {
reg = <7>;
active-low;
label = "green:wps";
};
inet_green@8 {
reg = <8>;
active-low;
label = "green:inet";
};
ephy0_act@9 {
reg = <9>;
brcm,hardware-controlled;
};
ephy1_act@10 {
reg = <10>;
brcm,hardware-controlled;
};
ephy2_act@11 {
reg = <11>;
brcm,hardware-controlled;
};
gphy0_act@12 {
reg = <12>;
brcm,hardware-controlled;
};
ephy0_spd@13 {
reg = <13>;
brcm,hardware-controlled;
};
ephy1_spd@14 {
reg = <14>;
brcm,hardware-controlled;
};
ephy2_spd@15 {
reg = <15>;
brcm,hardware-controlled;
};
power_green@20 {
reg = <20>;
active-low;
label = "green:power";
default-state = "on";
};
};
Scenario 3 : BCM6362 with 1 LED for each EPHY
leds0: led-controller@10001900 {
compatible = "brcm,bcm6328-leds";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x10001900 0x24>;
usb@0 {
reg = <0>;
brcm,hardware-controlled;
brcm,link-signal-sources = <0>;
brcm,activity-signal-sources = <0>;
/* USB link/activity routed to USB LED */
};
inet@1 {
reg = <1>;
brcm,hardware-controlled;
brcm,activity-signal-sources = <1>;
/* INET activity routed to INET LED */
};
ephy0@4 {
reg = <4>;
brcm,hardware-controlled;
brcm,link-signal-sources = <4>;
/* EPHY0 link routed to EPHY0 LED */
};
ephy1@5 {
reg = <5>;
brcm,hardware-controlled;
brcm,link-signal-sources = <5>;
/* EPHY1 link routed to EPHY1 LED */
};
ephy2@6 {
reg = <6>;
brcm,hardware-controlled;
brcm,link-signal-sources = <6>;
/* EPHY2 link routed to EPHY2 LED */
};
ephy3@7 {
reg = <7>;
brcm,hardware-controlled;
brcm,link-signal-sources = <7>;
/* EPHY3 link routed to EPHY3 LED */
};
power_green@20 {
reg = <20>;
active-low;
label = "green:power";
default-state = "on";
};
};
Scenario 4 : BCM6362 with 1 LED for all EPHYs
leds0: led-controller@10001900 {
compatible = "brcm,bcm6328-leds";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x10001900 0x24>;
usb@0 {
reg = <0>;
brcm,hardware-controlled;
brcm,link-signal-sources = <0 1>;
brcm,activity-signal-sources = <0 1>;
/* USB/INET link/activity routed to USB LED */
};
ephy@4 {
reg = <4>;
brcm,hardware-controlled;
brcm,link-signal-sources = <4 5 6 7>;
/* EPHY0/1/2/3 link routed to EPHY0 LED */
};
power_green@20 {
reg = <20>;
active-low;
label = "green:power";
default-state = "on";
};
};
Scenario 5 : BCM6362 with EPHY LEDs swapped
leds0: led-controller@10001900 {
compatible = "brcm,bcm6328-leds";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x10001900 0x24>;
usb@0 {
reg = <0>;
brcm,hardware-controlled;
brcm,link-signal-sources = <0>;
brcm,activity-signal-sources = <0 1>;
/* USB link/act and INET act routed to USB LED */
};
ephy0@4 {
reg = <4>;
brcm,hardware-controlled;
brcm,link-signal-sources = <7>;
/* EPHY3 link routed to EPHY0 LED */
};
ephy1@5 {
reg = <5>;
brcm,hardware-controlled;
brcm,link-signal-sources = <6>;
/* EPHY2 link routed to EPHY1 LED */
};
ephy2@6 {
reg = <6>;
brcm,hardware-controlled;
brcm,link-signal-sources = <5>;
/* EPHY1 link routed to EPHY2 LED */
};
ephy3@7 {
reg = <7>;
brcm,hardware-controlled;
brcm,link-signal-sources = <4>;
/* EPHY0 link routed to EPHY3 LED */
};
power_green@20 {
reg = <20>;
active-low;
label = "green:power";
default-state = "on";
};
};
This diff is collapsed.
......@@ -175,15 +175,6 @@ required:
- ti,mbox-num-fifos
allOf:
- if:
properties:
compatible:
enum:
- ti,am654-mailbox
then:
required:
- interrupt-parent
- if:
properties:
compatible:
......
......@@ -129,11 +129,8 @@ patternProperties:
The child device node represents the device connected to the GPMC
bus. The device can be a NAND chip, SRAM device, NOR device
or an ASIC.
$ref: "ti,gpmc-child.yaml"
allOf:
- $ref: "ti,gpmc-child.yaml"
unevaluatedProperties: false
required:
- compatible
......
......@@ -221,7 +221,6 @@ required:
- '#gpio-cells'
- interrupt-controller
- '#interrupt-cells'
- interrupt-parent
- interrupts
- AVDD-supply
- DBVDD1-supply
......
......@@ -51,6 +51,10 @@ properties:
description:
Phandle to the device containing custom config.
mdio:
$ref: mdio.yaml#
unevaluatedProperties: false
required:
- compatible
- reg
......
......@@ -122,6 +122,7 @@ allOf:
mdio-mux:
type: object
unevaluatedProperties: false
properties:
compatible:
......@@ -132,17 +133,18 @@ allOf:
description:
Phandle to EMAC MDIO.
"#address-cells":
const: 1
"#size-cells":
const: 0
mdio@1:
type: object
$ref: mdio.yaml#
unevaluatedProperties: false
description: Internal MDIO Bus
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
compatible:
const: allwinner,sun8i-h3-mdio-internal
......@@ -168,16 +170,11 @@ allOf:
mdio@2:
type: object
$ref: mdio.yaml#
unevaluatedProperties: false
description: External MDIO Bus (H3 only)
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
reg:
const: 2
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
......@@ -7,6 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom UniMAC MDIO bus controller
maintainers:
- Doug Berger <opendmb@gmail.com>
- Florian Fainelli <f.fainelli@gmail.com>
- Rafał Miłecki <rafal@milecki.pl>
allOf:
......@@ -64,7 +66,6 @@ unevaluatedProperties: false
required:
- reg
- reg-names
- '#address-cells'
- '#size-cells'
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment