mirror of
https://github.com/torvalds/linux.git
synced 2026-09-24 06:24:02 +02:00
dt-bindings: Drop incorrect usage of double '::'
There is no use of double colon '::' in YAML. OTOH, the literal style block, e.g. using '|' treats all characters as content [1] therefore single use of ':' in descriptions is perfectly fine, whenever '|' is used. Cleanup existing code, so the confusing style won't be re-used in new contributions. Link: https://yaml.org/spec/1.2.2/#literal-style [1] Acked-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patch.msgid.link/20260623054842.21831-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
This commit is contained in:
Krzysztof Kozlowski
Rob Herring (Arm)
parent
b3edadcb9e
commit
5de561db57
|
|
@ -11,10 +11,10 @@ maintainers:
|
|||
|
||||
description: |
|
||||
Guidelines for new compatibles for SoC blocks/components.
|
||||
When adding new compatibles in new bindings, use the format::
|
||||
When adding new compatibles in new bindings, use the format:
|
||||
qcom,SoC-IP
|
||||
|
||||
For example::
|
||||
For example:
|
||||
qcom,sdm845-llcc-bwmon
|
||||
|
||||
When adding new compatibles to existing bindings, use the format in the
|
||||
|
|
|
|||
|
|
@ -1215,7 +1215,7 @@ properties:
|
|||
items:
|
||||
items:
|
||||
- description: |
|
||||
MSM chipset ID - an exact match value consisting of two bitfields::
|
||||
MSM chipset ID - an exact match value consisting of two bitfields:
|
||||
- bits 0-15 - The unique MSM chipset ID
|
||||
- bits 16-31 - Reserved; should be 0
|
||||
- description: |
|
||||
|
|
@ -1241,7 +1241,7 @@ properties:
|
|||
- items:
|
||||
- items:
|
||||
- description: |
|
||||
Board ID consisting of three bitfields::
|
||||
Board ID consisting of three bitfields:
|
||||
- bits 31-24 - Unused
|
||||
- bits 23-16 - Platform Version Major
|
||||
- bits 15-8 - Platform Version Minor
|
||||
|
|
|
|||
|
|
@ -11,10 +11,10 @@ maintainers:
|
|||
|
||||
description: |
|
||||
Guidelines for new compatibles for SoC blocks/components.
|
||||
When adding new compatibles in new bindings, use the format::
|
||||
When adding new compatibles in new bindings, use the format:
|
||||
samsung,SoC-IP
|
||||
|
||||
For example::
|
||||
For example:
|
||||
samsung,exynos5433-cmu-isp
|
||||
|
||||
select:
|
||||
|
|
|
|||
|
|
@ -73,16 +73,16 @@ properties:
|
|||
|
||||
clocks:
|
||||
description: |
|
||||
Several clocks are used, depending on the variant. Typical ones are::
|
||||
- bus:: Display AHB clock.
|
||||
- byte:: Display byte clock.
|
||||
- byte_intf:: Display byte interface clock.
|
||||
- core:: Display core clock.
|
||||
- core_mss:: Core MultiMedia SubSystem clock.
|
||||
- iface:: Display AXI clock.
|
||||
- mdp_core:: MDP Core clock.
|
||||
- mnoc:: MNOC clock
|
||||
- pixel:: Display pixel clock.
|
||||
Several clocks are used, depending on the variant. Typical ones are:
|
||||
- bus: Display AHB clock.
|
||||
- byte: Display byte clock.
|
||||
- byte_intf: Display byte interface clock.
|
||||
- core: Display core clock.
|
||||
- core_mss: Core MultiMedia SubSystem clock.
|
||||
- iface: Display AXI clock.
|
||||
- mdp_core: MDP Core clock.
|
||||
- mnoc: MNOC clock
|
||||
- pixel: Display pixel clock.
|
||||
minItems: 3
|
||||
maxItems: 12
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ properties:
|
|||
additionalProperties: false
|
||||
description: |
|
||||
Timing configuration for lcd i80 interface support.
|
||||
The parameters are defined as::
|
||||
The parameters are defined as:
|
||||
VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|??
|
||||
: : : : :
|
||||
Address Output --:<XXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XX
|
||||
|
|
@ -132,7 +132,7 @@ patternProperties:
|
|||
"^port@[0-4]+$":
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description: |
|
||||
Contains ports with port with index::
|
||||
Contains ports with port with index:
|
||||
0 - for CAMIF0 input,
|
||||
1 - for CAMIF1 input,
|
||||
2 - for CAMIF2 input,
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ properties:
|
|||
|
||||
gpios:
|
||||
description: |
|
||||
The order of the GPIOs should be the following:: <SDA, SCL>. The GPIO
|
||||
The order of the GPIOs should be the following: <SDA, SCL>. The GPIO
|
||||
specifier depends on the gpio controller. Required in all cases except
|
||||
for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are
|
||||
permanently wired to the respective client.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ description: |
|
|||
Bandwidth Monitor measures current throughput on buses between various NoC
|
||||
fabrics and provides information when it crosses configured thresholds.
|
||||
|
||||
Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845::
|
||||
Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845:
|
||||
- Measuring the bandwidth between CPUs and Last Level Cache Controller -
|
||||
called just BWMON,
|
||||
- Measuring the bandwidth between Last Level Cache Controller and memory
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ description: |
|
|||
The each AXI bus has the owned source clock but, has not the only owned power
|
||||
line. The power line might be shared among one more sub-blocks. So, we can
|
||||
divide into two type of device as the role of each sub-block. There are two
|
||||
type of bus devices as following::
|
||||
type of bus devices as following:
|
||||
- parent bus device
|
||||
- passive bus device
|
||||
|
||||
|
|
@ -44,8 +44,8 @@ description: |
|
|||
able to support the bus frequency for all Exynos SoCs.
|
||||
|
||||
Detailed correlation between sub-blocks and power line according
|
||||
to Exynos SoC::
|
||||
- In case of Exynos3250, there are two power line as following::
|
||||
to Exynos SoC:
|
||||
- In case of Exynos3250, there are two power line as following:
|
||||
VDD_MIF |--- DMC (Dynamic Memory Controller)
|
||||
|
||||
VDD_INT |--- LEFTBUS (parent device)
|
||||
|
|
@ -89,7 +89,7 @@ description: |
|
|||
|L5 |200000 |200000 |400000 |300000 | ||1000000 |
|
||||
----------------------------------------------------------
|
||||
|
||||
- In case of Exynos4210, there is one power line as following::
|
||||
- In case of Exynos4210, there is one power line as following:
|
||||
VDD_INT |--- DMC (parent device, Dynamic Memory Controller)
|
||||
|--- LEFTBUS
|
||||
|--- PERIL
|
||||
|
|
@ -106,7 +106,7 @@ description: |
|
|||
|--- LCD0
|
||||
|--- LCD1
|
||||
|
||||
- In case of Exynos4x12, there are two power line as following::
|
||||
- In case of Exynos4x12, there are two power line as following:
|
||||
VDD_MIF |--- DMC (Dynamic Memory Controller)
|
||||
|
||||
VDD_INT |--- LEFTBUS (parent device)
|
||||
|
|
@ -124,7 +124,7 @@ description: |
|
|||
|--- LCD0
|
||||
|--- ISP
|
||||
|
||||
- In case of Exynos5422, there are two power line as following::
|
||||
- In case of Exynos5422, there are two power line as following:
|
||||
VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller)
|
||||
|--- DREX 1
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ description: |
|
|||
|--- FSYS
|
||||
|--- FSYS2
|
||||
|
||||
- In case of Exynos5433, there is VDD_INT power line as following::
|
||||
- In case of Exynos5433, there is VDD_INT power line as following:
|
||||
VDD_INT |--- G2D (parent device)
|
||||
|--- MSCL
|
||||
|--- GSCL
|
||||
|
|
|
|||
|
|
@ -10,10 +10,10 @@ maintainers:
|
|||
- Krzysztof Kozlowski <krzk@kernel.org>
|
||||
|
||||
description: |
|
||||
The Qualcomm PM8058 contains an LED block for up to six LEDs:: three normal
|
||||
The Qualcomm PM8058 contains an LED block for up to six LEDs: three normal
|
||||
LEDs, two "flash" LEDs and one "keypad backlight" LED. The names are quoted
|
||||
because sometimes these LED drivers are used for wildly different things than
|
||||
flash or keypad backlight:: their names are more of a suggestion than a
|
||||
flash or keypad backlight: their names are more of a suggestion than a
|
||||
hard-wired usecase.
|
||||
|
||||
Hardware-wise the different LEDs support slightly different output currents.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ maintainers:
|
|||
- Krzysztof Kozlowski <krzk@kernel.org>
|
||||
|
||||
description: |
|
||||
The device is controlled through two pins:: FL_EN and EN_SET. The pins when,
|
||||
The device is controlled through two pins: FL_EN and EN_SET. The pins when,
|
||||
asserted high, enable flash strobe and movie mode (max 1/2 of flash current)
|
||||
respectively. In order to add a capability of selecting the strobe signal
|
||||
source (e.g. CPU or camera sensor) there is an additional switch required,
|
||||
|
|
@ -39,11 +39,11 @@ properties:
|
|||
flash-max-microamp:
|
||||
description: |
|
||||
Maximum flash LED supply current can be calculated using following
|
||||
formula:: I = 1A * 162 kOhm / Rset.
|
||||
formula: I = 1A * 162 kOhm / Rset.
|
||||
|
||||
flash-max-timeout-us:
|
||||
description: |
|
||||
Maximum flash timeout can be calculated using following formula::
|
||||
Maximum flash timeout can be calculated using following formula:
|
||||
T = 8.82 * 10^9 * Ct.
|
||||
|
||||
required:
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ description: |
|
|||
hooked up to a pull-up GPIO line and - optionally - the HPD line is hooked up
|
||||
to another GPIO line.
|
||||
|
||||
Please note:: the maximum voltage for the CEC line is 3.63V, for the HPD and
|
||||
Please note: the maximum voltage for the CEC line is 3.63V, for the HPD and
|
||||
5V lines it is 5.3V. So you may need some sort of level conversion
|
||||
circuitry when connecting them to a GPIO line.
|
||||
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ properties:
|
|||
description: |
|
||||
The value of CIU TX and RX clock phase shift value for HS400 mode
|
||||
operation.
|
||||
Valid values for SDR and DDR CIU clock timing::
|
||||
Valid values for SDR and DDR CIU clock timing:
|
||||
- valid value for tx phase shift and rx phase shift is 0 to 7.
|
||||
- when CIU clock divider value is set to 3, all possible 8 phase shift
|
||||
values can be used.
|
||||
|
|
|
|||
|
|
@ -13,14 +13,14 @@ maintainers:
|
|||
|
||||
description: |
|
||||
For samsung,s5pv210-mipi-video-phy compatible PHYs the second cell in the
|
||||
PHY specifier identifies the PHY and its meaning is as follows::
|
||||
PHY specifier identifies the PHY and its meaning is as follows:
|
||||
0 - MIPI CSIS 0,
|
||||
1 - MIPI DSIM 0,
|
||||
2 - MIPI CSIS 1,
|
||||
3 - MIPI DSIM 1.
|
||||
|
||||
samsung,exynos5420-mipi-video-phy and samsung,exynos5433-mipi-video-phy
|
||||
support additional fifth PHY::
|
||||
support additional fifth PHY:
|
||||
4 - MIPI CSIS 2.
|
||||
|
||||
properties:
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ maintainers:
|
|||
description: |
|
||||
The first phandle argument in the PHY specifier identifies the PHY, its
|
||||
meaning is compatible dependent. For the currently supported SoCs (Exynos4210
|
||||
and Exynos4212) it is as follows::
|
||||
and Exynos4212) it is as follows:
|
||||
0 - USB device ("device"),
|
||||
1 - USB host ("host"),
|
||||
2 - HSIC0 ("hsic0"),
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ maintainers:
|
|||
description: |
|
||||
For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
|
||||
compatible PHYs, the second cell in the PHY specifier identifies the
|
||||
PHY id, which is interpreted as follows::
|
||||
PHY id, which is interpreted as follows:
|
||||
0 - UTMI+ type phy,
|
||||
1 - PIPE3 type phy.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ description: |
|
|||
All the pin controller nodes should be represented in the aliases node using
|
||||
the following format 'pinctrl{n}' where n is a unique number for the alias.
|
||||
|
||||
The controller supports three types of interrupts::
|
||||
The controller supports three types of interrupts:
|
||||
- External GPIO interrupts (see interrupts property in pin controller node);
|
||||
|
||||
- External wake-up interrupts - multiplexed (capable of waking up the system
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ maintainers:
|
|||
description: |
|
||||
The R-Car (RZ/G) System Controller provides power management for the CPU
|
||||
cores and various coprocessors.
|
||||
The power domain IDs for consumers are defined in header files::
|
||||
The power domain IDs for consumers are defined in header files:
|
||||
include/dt-bindings/power/r8*-sysc.h
|
||||
|
||||
properties:
|
||||
|
|
|
|||
|
|
@ -18,12 +18,12 @@ properties:
|
|||
priority:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
A priority ranging from 0 to 255 according to the following guidelines::
|
||||
0:: Restart handler of last resort, with limited restart capabilities.
|
||||
128:: Typical, default restart handler; use if no other restart handler
|
||||
A priority ranging from 0 to 255 according to the following guidelines:
|
||||
0: Restart handler of last resort, with limited restart capabilities.
|
||||
128: Typical, default restart handler; use if no other restart handler
|
||||
is expected to be available, and/or if restart functionality is
|
||||
sufficient to restart the entire system.
|
||||
255:: Highest priority restart handler, will preempt all other restart handlers.
|
||||
255: Highest priority restart handler, will preempt all other restart handlers.
|
||||
minimum: 0
|
||||
maximum: 255
|
||||
|
||||
|
|
|
|||
|
|
@ -22,13 +22,13 @@ description: |
|
|||
|
||||
Certain regulators support "regulator-initial-mode" and "regulator-mode".
|
||||
The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h
|
||||
and their meaning is::
|
||||
and their meaning is:
|
||||
1 - Normal regulator voltage output mode.
|
||||
3 - Low Power which reduces the quiescent current down to only 1uA
|
||||
|
||||
The standard "regulator-mode" property can only be used for regulators that
|
||||
support changing their mode to Low Power Mode during suspend. These
|
||||
regulators are:: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
|
||||
regulators are: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
|
||||
regulator has been enabled for the given suspend state using
|
||||
"regulator-on-in-suspend" and has not been disabled for that state using
|
||||
"regulator-off-in-suspend".
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ description: |
|
|||
conduction mode (FCCM).
|
||||
|
||||
The definition of modes is in the datasheet which is available in below link
|
||||
and their meaning is::
|
||||
and their meaning is:
|
||||
0 - Auto mode for power saving, which reducing the switching frequency at light load condition
|
||||
to maintain high frequency.
|
||||
1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ description: |
|
|||
software perspective it's mostly compatible with the MSM serial UART except
|
||||
that it supports reading and writing multiple characters at a time.
|
||||
|
||||
Note:: Aliases may be defined to ensure the correct ordering of the UARTs.
|
||||
Note: Aliases may be defined to ensure the correct ordering of the UARTs.
|
||||
The alias serialN will result in the UART being assigned port N. If any
|
||||
serialN alias exists, then an alias must exist for each enabled UART. The
|
||||
serialN aliases should be in a .dts file instead of in a .dtsi file.
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ patternProperties:
|
|||
description: |
|
||||
Every SLIMbus controller node can contain zero or more child nodes
|
||||
representing slave devices on the bus. Every SLIMbus slave device is
|
||||
uniquely determined by the enumeration address containing 4 fields::
|
||||
uniquely determined by the enumeration address containing 4 fields:
|
||||
Manufacturer ID, Product code, Device index, and Instance value for the
|
||||
device.
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ patternProperties:
|
|||
reg:
|
||||
maxItems: 1
|
||||
description: |
|
||||
Pair of (device index, instande ID), where::
|
||||
Pair of (device index, instande ID), where:
|
||||
- Device index, which uniquely identifies multiple devices within a
|
||||
single component.
|
||||
- Instance ID, can be used for the cases where multiple devices of
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ properties:
|
|||
$ref: /schemas/types.yaml#/definitions/string-array
|
||||
description: |
|
||||
Protection domain service name and path for APR service (if supported).
|
||||
Possible values are::
|
||||
Possible values are:
|
||||
"avs/audio", "msm/adsp/audio_pd".
|
||||
"kernel/elf_loader", "msm/modem/wlan_pd".
|
||||
"tms/servreg", "msm/adsp/audio_pd".
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ description: |
|
|||
with a few variations that are captured by the properties here.
|
||||
|
||||
A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
|
||||
have powered off to facilitate idle power saving. TCS could be classified as::
|
||||
have powered off to facilitate idle power saving. TCS could be classified as:
|
||||
ACTIVE - Triggered by Linux
|
||||
SLEEP - Triggered by F/W
|
||||
WAKE - Triggered by F/W
|
||||
|
|
@ -76,7 +76,7 @@ properties:
|
|||
items:
|
||||
items:
|
||||
- description: |
|
||||
TCS type::
|
||||
TCS type:
|
||||
- ACTIVE_TCS
|
||||
- SLEEP_TCS
|
||||
- WAKE_TCS
|
||||
|
|
@ -152,7 +152,7 @@ examples:
|
|||
- |
|
||||
// For a TCS whose RSC base address is 0x179C0000 and is at a DRV id of
|
||||
// 2, the register offsets for DRV2 start at 0D00, the register
|
||||
// calculations are like this::
|
||||
// calculations are like this:
|
||||
// DRV0: 0x179C0000
|
||||
// DRV2: 0x179C0000 + 0x10000 = 0x179D0000
|
||||
// DRV2: 0x179C0000 + 0x10000 * 2 = 0x179E0000
|
||||
|
|
@ -182,7 +182,7 @@ examples:
|
|||
- |
|
||||
// For a TCS whose RSC base address is 0xAF20000 and is at DRV id of 0, the
|
||||
// register offsets for DRV0 start at 01C00, the register calculations are
|
||||
// like this::
|
||||
// like this:
|
||||
// DRV0: 0xAF20000
|
||||
// TCS-OFFSET: 0x1C00
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ properties:
|
|||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: |
|
||||
Reference to a node specifying the wcnss "ccu" and "dxe" register blocks.
|
||||
The node must be compatible with one of the following::
|
||||
The node must be compatible with one of the following:
|
||||
- qcom,riva"
|
||||
- qcom,pronto"
|
||||
|
||||
|
|
|
|||
|
|
@ -12,10 +12,10 @@ maintainers:
|
|||
|
||||
description: |
|
||||
Guidelines for new compatibles for SoC blocks/components.
|
||||
When adding new compatibles in new bindings, use the format::
|
||||
When adding new compatibles in new bindings, use the format:
|
||||
renesas,SoC-IP
|
||||
|
||||
For example::
|
||||
For example:
|
||||
renesas,r8a77965-csi2
|
||||
|
||||
When adding new compatibles to existing bindings, use the format in the
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ patternProperties:
|
|||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 1, 2]
|
||||
description: |
|
||||
The direction of the dai stream::
|
||||
The direction of the dai stream:
|
||||
- Q6ASM_DAI_TX_RX (0) for both tx and rx
|
||||
- Q6ASM_DAI_TX (1) for only tx (Capture/Encode)
|
||||
- Q6ASM_DAI_RX (2) for only rx (Playback/Decode)
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ properties:
|
|||
description: |
|
||||
The Exynos TMU supports generating interrupts when reaching given
|
||||
temperature thresholds. Number of supported thermal trip points depends
|
||||
on the SoC (only first trip points defined in DT will be configured)::
|
||||
on the SoC (only first trip points defined in DT will be configured):
|
||||
- most of SoC: 4
|
||||
- samsung,exynos5433-tmu: 8
|
||||
- samsung,exynos7-tmu: 8
|
||||
|
|
@ -52,7 +52,7 @@ properties:
|
|||
- description: |
|
||||
Shared TMU registers.
|
||||
|
||||
Note:: On Exynos5420, the TRIMINFO register is misplaced for TMU
|
||||
Note: On Exynos5420, the TRIMINFO register is misplaced for TMU
|
||||
channels 2, 3 and 4 Use "samsung,exynos5420-tmu-ext-triminfo" in
|
||||
cases, there is a misplaced register, also provide clock to access
|
||||
that base.
|
||||
|
|
|
|||
|
|
@ -92,14 +92,14 @@ properties:
|
|||
|
||||
clocks:
|
||||
description: |
|
||||
Several clocks are used, depending on the variant. Typical ones are::
|
||||
- cfg_noc:: System Config NOC clock.
|
||||
- core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
|
||||
Several clocks are used, depending on the variant. Typical ones are:
|
||||
- cfg_noc: System Config NOC clock.
|
||||
- core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
|
||||
60MHz for HS operation.
|
||||
- iface:: System bus AXI clock.
|
||||
- sleep:: Sleep clock, used for wakeup when USB3 core goes into low
|
||||
- iface: System bus AXI clock.
|
||||
- sleep: Sleep clock, used for wakeup when USB3 core goes into low
|
||||
power mode (U3).
|
||||
- mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
|
||||
- mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
|
||||
mode. Its frequency should be 19.2MHz.
|
||||
minItems: 1
|
||||
maxItems: 9
|
||||
|
|
|
|||
|
|
@ -87,14 +87,14 @@ properties:
|
|||
|
||||
clocks:
|
||||
description: |
|
||||
Several clocks are used, depending on the variant. Typical ones are::
|
||||
- cfg_noc:: System Config NOC clock.
|
||||
- core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
|
||||
Several clocks are used, depending on the variant. Typical ones are:
|
||||
- cfg_noc: System Config NOC clock.
|
||||
- core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
|
||||
60MHz for HS operation.
|
||||
- iface:: System bus AXI clock.
|
||||
- sleep:: Sleep clock, used for wakeup when USB3 core goes into low
|
||||
- iface: System bus AXI clock.
|
||||
- sleep: Sleep clock, used for wakeup when USB3 core goes into low
|
||||
power mode (U3).
|
||||
- mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
|
||||
- mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
|
||||
mode. Its frequency should be 19.2MHz.
|
||||
minItems: 1
|
||||
maxItems: 9
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user