mirror of
https://github.com/torvalds/linux.git
synced 2026-06-07 14:04:54 +02:00
Merge 5.4-rc1-prereleae into android-mainline
To make the 5.4-rc1 merge easier, merge at a prerelease point in time before the final release happens. Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> Change-Id: I29b683c837ed1a3324644dbf9bf863f30740cd0b
This commit is contained in:
Greg Kroah-Hartman
commit
896be8f44d
3
.gitignore
vendored
3
.gitignore
vendored
|
|
@ -32,9 +32,9 @@
|
|||
*.lzo
|
||||
*.mod
|
||||
*.mod.c
|
||||
*.ns_deps
|
||||
*.o
|
||||
*.o.*
|
||||
*.order
|
||||
*.patch
|
||||
*.s
|
||||
*.so
|
||||
|
|
@ -46,6 +46,7 @@
|
|||
*.xz
|
||||
Module.symvers
|
||||
modules.builtin
|
||||
modules.order
|
||||
|
||||
#
|
||||
# Top-level generic files
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Description: The /dev/kmsg character device node provides userspace access
|
|||
The logged line can be prefixed with a <N> syslog prefix, which
|
||||
carries the syslog priority and facility. The single decimal
|
||||
prefix number is composed of the 3 lowest bits being the syslog
|
||||
priority and the higher bits the syslog facility number.
|
||||
priority and the next 8 bits the syslog facility number.
|
||||
|
||||
If no prefix is given, the priority number is the default kernel
|
||||
log priority and the facility number is set to LOG_USER (1). It
|
||||
|
|
@ -90,13 +90,12 @@ Description: The /dev/kmsg character device node provides userspace access
|
|||
+sound:card0 - subsystem:devname
|
||||
|
||||
The flags field carries '-' by default. A 'c' indicates a
|
||||
fragment of a line. All following fragments are flagged with
|
||||
'+'. Note, that these hints about continuation lines are not
|
||||
necessarily correct, and the stream could be interleaved with
|
||||
unrelated messages, but merging the lines in the output
|
||||
usually produces better human readable results. A similar
|
||||
logic is used internally when messages are printed to the
|
||||
console, /proc/kmsg or the syslog() syscall.
|
||||
fragment of a line. Note, that these hints about continuation
|
||||
lines are not necessarily correct, and the stream could be
|
||||
interleaved with unrelated messages, but merging the lines in
|
||||
the output usually produces better human readable results. A
|
||||
similar logic is used internally when messages are printed to
|
||||
the console, /proc/kmsg or the syslog() syscall.
|
||||
|
||||
By default, kernel tries to avoid fragments by concatenating
|
||||
when it can and fragments are rare; however, when extended
|
||||
|
|
|
|||
|
|
@ -48,3 +48,13 @@ Description: Remote processor state
|
|||
|
||||
Writing "stop" will attempt to halt the remote processor and
|
||||
return it to the "offline" state.
|
||||
|
||||
What: /sys/class/remoteproc/.../name
|
||||
Date: August 2019
|
||||
KernelVersion: 5.4
|
||||
Contact: Suman Anna <s-anna@ti.com>
|
||||
Description: Remote processor name
|
||||
|
||||
Reports the name of the remote processor. This can be used by
|
||||
userspace in exactly identifying a remote processor and ease
|
||||
up the usage in modifying the 'firmware' or 'state' files.
|
||||
|
|
|
|||
|
|
@ -562,3 +562,13 @@ Description: Umwait control
|
|||
or C0.2 state. The time is an unsigned 32-bit number.
|
||||
Note that a value of zero means there is no limit.
|
||||
Low order two bits must be zero.
|
||||
|
||||
What: /sys/devices/system/cpu/svm
|
||||
Date: August 2019
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
|
||||
Description: Secure Virtual Machine
|
||||
|
||||
If 1, it means the system is using the Protected Execution
|
||||
Facility in POWER9 and newer processors. i.e., it is a Secure
|
||||
Virtual Machine.
|
||||
|
|
|
|||
|
|
@ -251,3 +251,10 @@ Description:
|
|||
If checkpoint=disable, it displays the number of blocks that are unusable.
|
||||
If checkpoint=enable it displays the enumber of blocks that would be unusable
|
||||
if checkpoint=disable were to be set.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/encoding
|
||||
Date July 2019
|
||||
Contact: "Daniel Rosenberg" <drosen@google.com>
|
||||
Description:
|
||||
Displays name and version of the encoding set for the filesystem.
|
||||
If no encoding is set, displays (none)
|
||||
|
|
|
|||
|
|
@ -204,6 +204,14 @@ Returns the maximum size of a mapping for the device. The size parameter
|
|||
of the mapping functions like dma_map_single(), dma_map_page() and
|
||||
others should not be larger than the returned value.
|
||||
|
||||
::
|
||||
|
||||
unsigned long
|
||||
dma_get_merge_boundary(struct device *dev);
|
||||
|
||||
Returns the DMA merge boundary. If the device cannot merge any the DMA address
|
||||
segments, the function returns 0.
|
||||
|
||||
Part Id - Streaming DMA mappings
|
||||
--------------------------------
|
||||
|
||||
|
|
@ -595,17 +603,6 @@ For reasons of efficiency, most platforms choose to track the declared
|
|||
region only at the granularity of a page. For smaller allocations,
|
||||
you should use the dma_pool() API.
|
||||
|
||||
::
|
||||
|
||||
void
|
||||
dma_release_declared_memory(struct device *dev)
|
||||
|
||||
Remove the memory region previously declared from the system. This
|
||||
API performs *no* in-use checking for this region and will return
|
||||
unconditionally having removed all the required structures. It is the
|
||||
driver's job to ensure that no parts of this memory region are
|
||||
currently in use.
|
||||
|
||||
Part III - Debug drivers use of the DMA-API
|
||||
-------------------------------------------
|
||||
|
||||
|
|
|
|||
333
Documentation/admin-guide/device-mapper/dm-clone.rst
Normal file
333
Documentation/admin-guide/device-mapper/dm-clone.rst
Normal file
|
|
@ -0,0 +1,333 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0-only
|
||||
|
||||
========
|
||||
dm-clone
|
||||
========
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
dm-clone is a device mapper target which produces a one-to-one copy of an
|
||||
existing, read-only source device into a writable destination device: It
|
||||
presents a virtual block device which makes all data appear immediately, and
|
||||
redirects reads and writes accordingly.
|
||||
|
||||
The main use case of dm-clone is to clone a potentially remote, high-latency,
|
||||
read-only, archival-type block device into a writable, fast, primary-type device
|
||||
for fast, low-latency I/O. The cloned device is visible/mountable immediately
|
||||
and the copy of the source device to the destination device happens in the
|
||||
background, in parallel with user I/O.
|
||||
|
||||
For example, one could restore an application backup from a read-only copy,
|
||||
accessible through a network storage protocol (NBD, Fibre Channel, iSCSI, AoE,
|
||||
etc.), into a local SSD or NVMe device, and start using the device immediately,
|
||||
without waiting for the restore to complete.
|
||||
|
||||
When the cloning completes, the dm-clone table can be removed altogether and be
|
||||
replaced, e.g., by a linear table, mapping directly to the destination device.
|
||||
|
||||
The dm-clone target reuses the metadata library used by the thin-provisioning
|
||||
target.
|
||||
|
||||
Glossary
|
||||
========
|
||||
|
||||
Hydration
|
||||
The process of filling a region of the destination device with data from
|
||||
the same region of the source device, i.e., copying the region from the
|
||||
source to the destination device.
|
||||
|
||||
Once a region gets hydrated we redirect all I/O regarding it to the destination
|
||||
device.
|
||||
|
||||
Design
|
||||
======
|
||||
|
||||
Sub-devices
|
||||
-----------
|
||||
|
||||
The target is constructed by passing three devices to it (along with other
|
||||
parameters detailed later):
|
||||
|
||||
1. A source device - the read-only device that gets cloned and source of the
|
||||
hydration.
|
||||
|
||||
2. A destination device - the destination of the hydration, which will become a
|
||||
clone of the source device.
|
||||
|
||||
3. A small metadata device - it records which regions are already valid in the
|
||||
destination device, i.e., which regions have already been hydrated, or have
|
||||
been written to directly, via user I/O.
|
||||
|
||||
The size of the destination device must be at least equal to the size of the
|
||||
source device.
|
||||
|
||||
Regions
|
||||
-------
|
||||
|
||||
dm-clone divides the source and destination devices in fixed sized regions.
|
||||
Regions are the unit of hydration, i.e., the minimum amount of data copied from
|
||||
the source to the destination device.
|
||||
|
||||
The region size is configurable when you first create the dm-clone device. The
|
||||
recommended region size is the same as the file system block size, which usually
|
||||
is 4KB. The region size must be between 8 sectors (4KB) and 2097152 sectors
|
||||
(1GB) and a power of two.
|
||||
|
||||
Reads and writes from/to hydrated regions are serviced from the destination
|
||||
device.
|
||||
|
||||
A read to a not yet hydrated region is serviced directly from the source device.
|
||||
|
||||
A write to a not yet hydrated region will be delayed until the corresponding
|
||||
region has been hydrated and the hydration of the region starts immediately.
|
||||
|
||||
Note that a write request with size equal to region size will skip copying of
|
||||
the corresponding region from the source device and overwrite the region of the
|
||||
destination device directly.
|
||||
|
||||
Discards
|
||||
--------
|
||||
|
||||
dm-clone interprets a discard request to a range that hasn't been hydrated yet
|
||||
as a hint to skip hydration of the regions covered by the request, i.e., it
|
||||
skips copying the region's data from the source to the destination device, and
|
||||
only updates its metadata.
|
||||
|
||||
If the destination device supports discards, then by default dm-clone will pass
|
||||
down discard requests to it.
|
||||
|
||||
Background Hydration
|
||||
--------------------
|
||||
|
||||
dm-clone copies continuously from the source to the destination device, until
|
||||
all of the device has been copied.
|
||||
|
||||
Copying data from the source to the destination device uses bandwidth. The user
|
||||
can set a throttle to prevent more than a certain amount of copying occurring at
|
||||
any one time. Moreover, dm-clone takes into account user I/O traffic going to
|
||||
the devices and pauses the background hydration when there is I/O in-flight.
|
||||
|
||||
A message `hydration_threshold <#regions>` can be used to set the maximum number
|
||||
of regions being copied, the default being 1 region.
|
||||
|
||||
dm-clone employs dm-kcopyd for copying portions of the source device to the
|
||||
destination device. By default, we issue copy requests of size equal to the
|
||||
region size. A message `hydration_batch_size <#regions>` can be used to tune the
|
||||
size of these copy requests. Increasing the hydration batch size results in
|
||||
dm-clone trying to batch together contiguous regions, so we copy the data in
|
||||
batches of this many regions.
|
||||
|
||||
When the hydration of the destination device finishes, a dm event will be sent
|
||||
to user space.
|
||||
|
||||
Updating on-disk metadata
|
||||
-------------------------
|
||||
|
||||
On-disk metadata is committed every time a FLUSH or FUA bio is written. If no
|
||||
such requests are made then commits will occur every second. This means the
|
||||
dm-clone device behaves like a physical disk that has a volatile write cache. If
|
||||
power is lost you may lose some recent writes. The metadata should always be
|
||||
consistent in spite of any crash.
|
||||
|
||||
Target Interface
|
||||
================
|
||||
|
||||
Constructor
|
||||
-----------
|
||||
|
||||
::
|
||||
|
||||
clone <metadata dev> <destination dev> <source dev> <region size>
|
||||
[<#feature args> [<feature arg>]* [<#core args> [<core arg>]*]]
|
||||
|
||||
================ ==============================================================
|
||||
metadata dev Fast device holding the persistent metadata
|
||||
destination dev The destination device, where the source will be cloned
|
||||
source dev Read only device containing the data that gets cloned
|
||||
region size The size of a region in sectors
|
||||
|
||||
#feature args Number of feature arguments passed
|
||||
feature args no_hydration or no_discard_passdown
|
||||
|
||||
#core args An even number of arguments corresponding to key/value pairs
|
||||
passed to dm-clone
|
||||
core args Key/value pairs passed to dm-clone, e.g. `hydration_threshold
|
||||
256`
|
||||
================ ==============================================================
|
||||
|
||||
Optional feature arguments are:
|
||||
|
||||
==================== =========================================================
|
||||
no_hydration Create a dm-clone instance with background hydration
|
||||
disabled
|
||||
no_discard_passdown Disable passing down discards to the destination device
|
||||
==================== =========================================================
|
||||
|
||||
Optional core arguments are:
|
||||
|
||||
================================ ==============================================
|
||||
hydration_threshold <#regions> Maximum number of regions being copied from
|
||||
the source to the destination device at any
|
||||
one time, during background hydration.
|
||||
hydration_batch_size <#regions> During background hydration, try to batch
|
||||
together contiguous regions, so we copy data
|
||||
from the source to the destination device in
|
||||
batches of this many regions.
|
||||
================================ ==============================================
|
||||
|
||||
Status
|
||||
------
|
||||
|
||||
::
|
||||
|
||||
<metadata block size> <#used metadata blocks>/<#total metadata blocks>
|
||||
<region size> <#hydrated regions>/<#total regions> <#hydrating regions>
|
||||
<#feature args> <feature args>* <#core args> <core args>*
|
||||
<clone metadata mode>
|
||||
|
||||
======================= =======================================================
|
||||
metadata block size Fixed block size for each metadata block in sectors
|
||||
#used metadata blocks Number of metadata blocks used
|
||||
#total metadata blocks Total number of metadata blocks
|
||||
region size Configurable region size for the device in sectors
|
||||
#hydrated regions Number of regions that have finished hydrating
|
||||
#total regions Total number of regions to hydrate
|
||||
#hydrating regions Number of regions currently hydrating
|
||||
#feature args Number of feature arguments to follow
|
||||
feature args Feature arguments, e.g. `no_hydration`
|
||||
#core args Even number of core arguments to follow
|
||||
core args Key/value pairs for tuning the core, e.g.
|
||||
`hydration_threshold 256`
|
||||
clone metadata mode ro if read-only, rw if read-write
|
||||
|
||||
In serious cases where even a read-only mode is deemed
|
||||
unsafe no further I/O will be permitted and the status
|
||||
will just contain the string 'Fail'. If the metadata
|
||||
mode changes, a dm event will be sent to user space.
|
||||
======================= =======================================================
|
||||
|
||||
Messages
|
||||
--------
|
||||
|
||||
`disable_hydration`
|
||||
Disable the background hydration of the destination device.
|
||||
|
||||
`enable_hydration`
|
||||
Enable the background hydration of the destination device.
|
||||
|
||||
`hydration_threshold <#regions>`
|
||||
Set background hydration threshold.
|
||||
|
||||
`hydration_batch_size <#regions>`
|
||||
Set background hydration batch size.
|
||||
|
||||
Examples
|
||||
========
|
||||
|
||||
Clone a device containing a file system
|
||||
---------------------------------------
|
||||
|
||||
1. Create the dm-clone device.
|
||||
|
||||
::
|
||||
|
||||
dmsetup create clone --table "0 1048576000 clone $metadata_dev $dest_dev \
|
||||
$source_dev 8 1 no_hydration"
|
||||
|
||||
2. Mount the device and trim the file system. dm-clone interprets the discards
|
||||
sent by the file system and it will not hydrate the unused space.
|
||||
|
||||
::
|
||||
|
||||
mount /dev/mapper/clone /mnt/cloned-fs
|
||||
fstrim /mnt/cloned-fs
|
||||
|
||||
3. Enable background hydration of the destination device.
|
||||
|
||||
::
|
||||
|
||||
dmsetup message clone 0 enable_hydration
|
||||
|
||||
4. When the hydration finishes, we can replace the dm-clone table with a linear
|
||||
table.
|
||||
|
||||
::
|
||||
|
||||
dmsetup suspend clone
|
||||
dmsetup load clone --table "0 1048576000 linear $dest_dev 0"
|
||||
dmsetup resume clone
|
||||
|
||||
The metadata device is no longer needed and can be safely discarded or reused
|
||||
for other purposes.
|
||||
|
||||
Known issues
|
||||
============
|
||||
|
||||
1. We redirect reads, to not-yet-hydrated regions, to the source device. If
|
||||
reading the source device has high latency and the user repeatedly reads from
|
||||
the same regions, this behaviour could degrade performance. We should use
|
||||
these reads as hints to hydrate the relevant regions sooner. Currently, we
|
||||
rely on the page cache to cache these regions, so we hopefully don't end up
|
||||
reading them multiple times from the source device.
|
||||
|
||||
2. Release in-core resources, i.e., the bitmaps tracking which regions are
|
||||
hydrated, after the hydration has finished.
|
||||
|
||||
3. During background hydration, if we fail to read the source or write to the
|
||||
destination device, we print an error message, but the hydration process
|
||||
continues indefinitely, until it succeeds. We should stop the background
|
||||
hydration after a number of failures and emit a dm event for user space to
|
||||
notice.
|
||||
|
||||
Why not...?
|
||||
===========
|
||||
|
||||
We explored the following alternatives before implementing dm-clone:
|
||||
|
||||
1. Use dm-cache with cache size equal to the source device and implement a new
|
||||
cloning policy:
|
||||
|
||||
* The resulting cache device is not a one-to-one mirror of the source device
|
||||
and thus we cannot remove the cache device once cloning completes.
|
||||
|
||||
* dm-cache writes to the source device, which violates our requirement that
|
||||
the source device must be treated as read-only.
|
||||
|
||||
* Caching is semantically different from cloning.
|
||||
|
||||
2. Use dm-snapshot with a COW device equal to the source device:
|
||||
|
||||
* dm-snapshot stores its metadata in the COW device, so the resulting device
|
||||
is not a one-to-one mirror of the source device.
|
||||
|
||||
* No background copying mechanism.
|
||||
|
||||
* dm-snapshot needs to commit its metadata whenever a pending exception
|
||||
completes, to ensure snapshot consistency. In the case of cloning, we don't
|
||||
need to be so strict and can rely on committing metadata every time a FLUSH
|
||||
or FUA bio is written, or periodically, like dm-thin and dm-cache do. This
|
||||
improves the performance significantly.
|
||||
|
||||
3. Use dm-mirror: The mirror target has a background copying/mirroring
|
||||
mechanism, but it writes to all mirrors, thus violating our requirement that
|
||||
the source device must be treated as read-only.
|
||||
|
||||
4. Use dm-thin's external snapshot functionality. This approach is the most
|
||||
promising among all alternatives, as the thinly-provisioned volume is a
|
||||
one-to-one mirror of the source device and handles reads and writes to
|
||||
un-provisioned/not-yet-cloned areas the same way as dm-clone does.
|
||||
|
||||
Still:
|
||||
|
||||
* There is no background copying mechanism, though one could be implemented.
|
||||
|
||||
* Most importantly, we want to support arbitrary block devices as the
|
||||
destination of the cloning process and not restrict ourselves to
|
||||
thinly-provisioned volumes. Thin-provisioning has an inherent metadata
|
||||
overhead, for maintaining the thin volume mappings, which significantly
|
||||
degrades performance.
|
||||
|
||||
Moreover, cloning a device shouldn't force the use of thin-provisioning. On
|
||||
the other hand, if we wish to use thin provisioning, we can just use a thin
|
||||
LV as dm-clone's destination device.
|
||||
|
|
@ -125,6 +125,13 @@ check_at_most_once
|
|||
blocks, and a hash block will not be verified any more after all the data
|
||||
blocks it covers have been verified anyway.
|
||||
|
||||
root_hash_sig_key_desc <key_description>
|
||||
This is the description of the USER_KEY that the kernel will lookup to get
|
||||
the pkcs7 signature of the roothash. The pkcs7 signature is used to validate
|
||||
the root hash during the creation of the device mapper block device.
|
||||
Verification of roothash depends on the config DM_VERITY_VERIFY_ROOTHASH_SIG
|
||||
being set in the kernel.
|
||||
|
||||
Theory of operation
|
||||
===================
|
||||
|
||||
|
|
|
|||
|
|
@ -860,6 +860,10 @@
|
|||
disable_radix [PPC]
|
||||
Disable RADIX MMU mode on POWER9
|
||||
|
||||
disable_tlbie [PPC]
|
||||
Disable TLBIE instruction. Currently does not work
|
||||
with KVM, with HASH MMU, or with coherent accelerators.
|
||||
|
||||
disable_cpu_apicid= [X86,APIC,SMP]
|
||||
Format: <int>
|
||||
The number of initial APIC ID for the
|
||||
|
|
@ -4641,6 +4645,11 @@
|
|||
/sys/power/pm_test). Only available when CONFIG_PM_DEBUG
|
||||
is set. Default value is 5.
|
||||
|
||||
svm= [PPC]
|
||||
Format: { on | off | y | n | 1 | 0 }
|
||||
This parameter controls use of the Protected
|
||||
Execution Facility on pSeries.
|
||||
|
||||
swapaccount=[0|1]
|
||||
[KNL] Enable accounting of swap in memory resource
|
||||
controller if no parameter or 1 is given or disable
|
||||
|
|
@ -5326,3 +5335,22 @@
|
|||
A hex value specifying bitmask with supplemental xhci
|
||||
host controller quirks. Meaning of each bit can be
|
||||
consulted in header drivers/usb/host/xhci.h.
|
||||
|
||||
xmon [PPC]
|
||||
Format: { early | on | rw | ro | off }
|
||||
Controls if xmon debugger is enabled. Default is off.
|
||||
Passing only "xmon" is equivalent to "xmon=early".
|
||||
early Call xmon as early as possible on boot; xmon
|
||||
debugger is called from setup_arch().
|
||||
on xmon debugger hooks will be installed so xmon
|
||||
is only called on a kernel crash. Default mode,
|
||||
i.e. either "ro" or "rw" mode, is controlled
|
||||
with CONFIG_XMON_DEFAULT_RO_MODE.
|
||||
rw xmon debugger hooks will be installed so xmon
|
||||
is called only on a kernel crash, mode is write,
|
||||
meaning SPR registers, memory and, other data
|
||||
can be written using xmon commands.
|
||||
ro same as "rw" option above but SPR registers,
|
||||
memory, and other data can't be written using
|
||||
xmon commands.
|
||||
off xmon is disabled.
|
||||
|
|
|
|||
|
|
@ -1,56 +0,0 @@
|
|||
Actions Semi platforms device tree bindings
|
||||
-------------------------------------------
|
||||
|
||||
|
||||
S500 SoC
|
||||
========
|
||||
|
||||
Required root node properties:
|
||||
|
||||
- compatible : must contain "actions,s500"
|
||||
|
||||
|
||||
Modules:
|
||||
|
||||
Root node property compatible must contain, depending on module:
|
||||
|
||||
- LeMaker Guitar: "lemaker,guitar"
|
||||
|
||||
|
||||
Boards:
|
||||
|
||||
Root node property compatible must contain, depending on board:
|
||||
|
||||
- Allo.com Sparky: "allo,sparky"
|
||||
- Cubietech CubieBoard6: "cubietech,cubieboard6"
|
||||
- LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", "lemaker,guitar"
|
||||
|
||||
|
||||
S700 SoC
|
||||
========
|
||||
|
||||
Required root node properties:
|
||||
|
||||
- compatible : must contain "actions,s700"
|
||||
|
||||
|
||||
Boards:
|
||||
|
||||
Root node property compatible must contain, depending on board:
|
||||
|
||||
- Cubietech CubieBoard7: "cubietech,cubieboard7"
|
||||
|
||||
|
||||
S900 SoC
|
||||
========
|
||||
|
||||
Required root node properties:
|
||||
|
||||
- compatible : must contain "actions,s900"
|
||||
|
||||
|
||||
Boards:
|
||||
|
||||
Root node property compatible must contain, depending on board:
|
||||
|
||||
- uCRobotics Bubblegum-96: "ucrobotics,bubblegum-96"
|
||||
38
Documentation/devicetree/bindings/arm/actions.yaml
Normal file
38
Documentation/devicetree/bindings/arm/actions.yaml
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/actions.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Actions Semi platforms device tree bindings
|
||||
|
||||
maintainers:
|
||||
- Andreas Färber <afaerber@suse.de>
|
||||
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
# The Actions Semi S500 is a quad-core ARM Cortex-A9 SoC.
|
||||
- items:
|
||||
- enum:
|
||||
- allo,sparky # Allo.com Sparky
|
||||
- cubietech,cubieboard6 # Cubietech CubieBoard6
|
||||
- const: actions,s500
|
||||
- items:
|
||||
- enum:
|
||||
- lemaker,guitar-bb-rev-b # LeMaker Guitar Base Board rev. B
|
||||
- const: lemaker,guitar
|
||||
- const: actions,s500
|
||||
|
||||
# The Actions Semi S700 is a quad-core ARM Cortex-A53 SoC.
|
||||
- items:
|
||||
- enum:
|
||||
- cubietech,cubieboard7 # Cubietech CubieBoard7
|
||||
- const: actions,s700
|
||||
|
||||
# The Actions Semi S900 is a quad-core ARM Cortex-A53 SoC.
|
||||
- items:
|
||||
- enum:
|
||||
- ucrobotics,bubblegum-96 # uCRobotics Bubblegum-96
|
||||
- const: actions,s900
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
Amlogic Meson Firmware registers Interface
|
||||
------------------------------------------
|
||||
|
||||
The Meson SoCs have a register bank with status and data shared with the
|
||||
secure firmware.
|
||||
|
||||
Required properties:
|
||||
- compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon"
|
||||
|
||||
Properties should indentify components of this register interface :
|
||||
|
||||
Meson GX SoC Information
|
||||
------------------------
|
||||
A firmware register encodes the SoC type, package and revision information on
|
||||
the Meson GX SoCs.
|
||||
If present, the following property should be added :
|
||||
|
||||
Optional properties:
|
||||
- amlogic,has-chip-id: If present, the interface gives the current SoC version.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
ao-secure@140 {
|
||||
compatible = "amlogic,meson-gx-ao-secure", "syscon";
|
||||
reg = <0x0 0x140 0x0 0x140>;
|
||||
amlogic,has-chip-id;
|
||||
};
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
# Copyright 2019 BayLibre, SAS
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Amlogic Meson Firmware registers Interface
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
|
||||
description: |
|
||||
The Meson SoCs have a register bank with status and data shared with the
|
||||
secure firmware.
|
||||
|
||||
# We need a select here so we don't match all nodes with 'syscon'
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: amlogic,meson-gx-ao-secure
|
||||
required:
|
||||
- compatible
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: amlogic,meson-gx-ao-secure
|
||||
- const: syscon
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
amlogic,has-chip-id:
|
||||
description: |
|
||||
A firmware register encodes the SoC type, package and revision
|
||||
information on the Meson GX SoCs. If present, the interface gives
|
||||
the current SoC version.
|
||||
type: boolean
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
examples:
|
||||
- |
|
||||
ao-secure@140 {
|
||||
compatible = "amlogic,meson-gx-ao-secure", "syscon";
|
||||
reg = <0x140 0x140>;
|
||||
amlogic,has-chip-id;
|
||||
};
|
||||
|
|
@ -199,7 +199,7 @@ The description for the board must include:
|
|||
A detailed description of the bindings used for "psci" nodes is present
|
||||
in the psci.yaml file.
|
||||
- a "cpus" node describing the available cores and their associated
|
||||
"enable-method"s. For more details see cpus.txt file.
|
||||
"enable-method"s. For more details see cpus.yaml file.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -124,6 +124,7 @@ properties:
|
|||
- arm,cortex-a15
|
||||
- arm,cortex-a17
|
||||
- arm,cortex-a53
|
||||
- arm,cortex-a55
|
||||
- arm,cortex-a57
|
||||
- arm,cortex-a72
|
||||
- arm,cortex-a73
|
||||
|
|
@ -155,6 +156,7 @@ properties:
|
|||
- qcom,krait
|
||||
- qcom,kryo
|
||||
- qcom,kryo385
|
||||
- qcom,kryo485
|
||||
- qcom,scorpion
|
||||
|
||||
enable-method:
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ PM implementation to put the processor in different idle states (which include
|
|||
states listed above; "off" state is not an idle state since it does not have
|
||||
wake-up capabilities, hence it is not considered in this document).
|
||||
|
||||
Idle state parameters (eg entry latency) are platform specific and need to be
|
||||
Idle state parameters (e.g. entry latency) are platform specific and need to be
|
||||
characterized with bindings that provide the required information to OS PM
|
||||
code so that it can build the required tables and use them at runtime.
|
||||
|
||||
|
|
@ -90,24 +90,24 @@ These timing parameters can be used by an OS in different circumstances.
|
|||
|
||||
An idle CPU requires the expected min-residency time to select the most
|
||||
appropriate idle state based on the expected expiry time of the next IRQ
|
||||
(ie wake-up) that causes the CPU to return to the EXEC phase.
|
||||
(i.e. wake-up) that causes the CPU to return to the EXEC phase.
|
||||
|
||||
An operating system scheduler may need to compute the shortest wake-up delay
|
||||
for CPUs in the system by detecting how long will it take to get a CPU out
|
||||
of an idle state, eg:
|
||||
of an idle state, e.g.:
|
||||
|
||||
wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
|
||||
|
||||
In other words, the scheduler can make its scheduling decision by selecting
|
||||
(eg waking-up) the CPU with the shortest wake-up latency.
|
||||
The wake-up latency must take into account the entry latency if that period
|
||||
(e.g. waking-up) the CPU with the shortest wake-up delay.
|
||||
The wake-up delay must take into account the entry latency if that period
|
||||
has not expired. The abortable nature of the PREP period can be ignored
|
||||
if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
|
||||
the worst case since it depends on the CPU operating conditions, ie caches
|
||||
the worst case since it depends on the CPU operating conditions, i.e. caches
|
||||
state).
|
||||
|
||||
An OS has to reliably probe the wakeup-latency since some devices can enforce
|
||||
latency constraints guarantees to work properly, so the OS has to detect the
|
||||
latency constraint guarantees to work properly, so the OS has to detect the
|
||||
worst case wake-up latency it can incur if a CPU is allowed to enter an
|
||||
idle state, and possibly to prevent that to guarantee reliable device
|
||||
functioning.
|
||||
|
|
@ -183,15 +183,15 @@ and IDLE2:
|
|||
Graph 2: idle states min-residency example
|
||||
|
||||
In graph 2 above, that takes into account idle states entry/exit energy
|
||||
costs, it is clear that if the idle state residency time (ie time till next
|
||||
costs, it is clear that if the idle state residency time (i.e. time till next
|
||||
wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
|
||||
choice energywise.
|
||||
|
||||
This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
|
||||
than IDLE2.
|
||||
|
||||
However, the lower power consumption (ie shallower energy curve slope) of idle
|
||||
state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
|
||||
However, the lower power consumption (i.e. shallower energy curve slope) of
|
||||
idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
|
||||
efficient.
|
||||
|
||||
The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
|
||||
|
|
@ -214,8 +214,8 @@ processor idle states, defined as device tree nodes, are listed.
|
|||
|
||||
Usage: Optional - On ARM systems, it is a container of processor idle
|
||||
states nodes. If the system does not provide CPU
|
||||
power management capabilities or the processor just
|
||||
supports idle_standby an idle-states node is not
|
||||
power management capabilities, or the processor just
|
||||
supports idle_standby, an idle-states node is not
|
||||
required.
|
||||
|
||||
Description: idle-states node is a container node, where its
|
||||
|
|
@ -287,14 +287,14 @@ follows:
|
|||
Value type: <prop-encoded-array>
|
||||
Definition: u32 value representing worst case latency in
|
||||
microseconds required to enter the idle state.
|
||||
The exit-latency-us duration may be guaranteed
|
||||
only after entry-latency-us has passed.
|
||||
|
||||
- exit-latency-us
|
||||
Usage: Required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: u32 value representing worst case latency
|
||||
in microseconds required to exit the idle state.
|
||||
The exit-latency-us duration may be guaranteed
|
||||
only after entry-latency-us has passed.
|
||||
|
||||
- min-residency-us
|
||||
Usage: Required
|
||||
|
|
@ -342,8 +342,8 @@ follows:
|
|||
state.
|
||||
|
||||
In addition to the properties listed above, a state node may require
|
||||
additional properties specifics to the entry-method defined in the
|
||||
idle-states node, please refer to the entry-method bindings
|
||||
additional properties specific to the entry-method defined in the
|
||||
idle-states node. Please refer to the entry-method bindings
|
||||
documentation for properties definitions.
|
||||
|
||||
===========================================
|
||||
|
|
|
|||
|
|
@ -176,6 +176,10 @@ properties:
|
|||
description: disable parity checking on the L2 cache (L220 or PL310).
|
||||
type: boolean
|
||||
|
||||
marvell,ecc-enable:
|
||||
description: enable ECC protection on the L2 cache
|
||||
type: boolean
|
||||
|
||||
arm,outer-sync-disable:
|
||||
description: disable the outer sync operation on the L2 cache.
|
||||
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
|
||||
|
|
|
|||
|
|
@ -18,17 +18,19 @@ Clocks:
|
|||
-------
|
||||
|
||||
|
||||
The Device Tree node representing the AP806 system controller provides
|
||||
a number of clocks:
|
||||
The Device Tree node representing the AP806/AP807 system controller
|
||||
provides a number of clocks:
|
||||
|
||||
- 0: clock of CPU cluster 0
|
||||
- 1: clock of CPU cluster 1
|
||||
- 0: reference clock of CPU cluster 0
|
||||
- 1: reference clock of CPU cluster 1
|
||||
- 2: fixed PLL at 1200 Mhz
|
||||
- 3: MSS clock, derived from the fixed PLL
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be: "marvell,ap806-clock"
|
||||
- compatible: must be one of:
|
||||
* "marvell,ap806-clock"
|
||||
* "marvell,ap807-clock"
|
||||
- #clock-cells: must be set to 1
|
||||
|
||||
Pinctrl:
|
||||
|
|
@ -143,3 +145,33 @@ ap_syscon1: system-controller@6f8000 {
|
|||
#thermal-sensor-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
Cluster clocks:
|
||||
---------------
|
||||
|
||||
Device Tree Clock bindings for cluster clock of Marvell
|
||||
AP806/AP807. Each cluster contain up to 2 CPUs running at the same
|
||||
frequency.
|
||||
|
||||
Required properties:
|
||||
- compatible: must be one of:
|
||||
* "marvell,ap806-cpu-clock"
|
||||
* "marvell,ap807-cpu-clock"
|
||||
- #clock-cells : should be set to 1.
|
||||
|
||||
- clocks : shall be the input parent clock(s) phandle for the clock
|
||||
(one per cluster)
|
||||
|
||||
- reg: register range associated with the cluster clocks
|
||||
|
||||
ap_syscon1: system-controller@6f8000 {
|
||||
compatible = "marvell,armada-ap806-syscon1", "syscon", "simple-mfd";
|
||||
reg = <0x6f8000 0x1000>;
|
||||
|
||||
cpu_clk: clock-cpu@278 {
|
||||
compatible = "marvell,ap806-cpu-clock";
|
||||
clocks = <&ap_clk 0>, <&ap_clk 1>;
|
||||
#clock-cells = <1>;
|
||||
reg = <0x278 0xa30>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -48,3 +48,11 @@ avs: avs@11500 {
|
|||
compatible = "marvell,armada-3700-avs", "syscon";
|
||||
reg = <0x11500 0x40>;
|
||||
}
|
||||
|
||||
|
||||
CZ.NIC's Turris Mox SOHO router Device Tree Bindings
|
||||
----------------------------------------------------
|
||||
|
||||
Required root node property:
|
||||
|
||||
- compatible: must contain "cznic,turris-mox"
|
||||
|
|
|
|||
|
|
@ -78,8 +78,8 @@ Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt.
|
|||
|
||||
Required properties:
|
||||
|
||||
- compatible: "marvell,armada-7k-pinctrl",
|
||||
"marvell,armada-8k-cpm-pinctrl" or "marvell,armada-8k-cps-pinctrl"
|
||||
- compatible: "marvell,armada-7k-pinctrl", "marvell,armada-8k-cpm-pinctrl",
|
||||
"marvell,armada-8k-cps-pinctrl" or "marvell,cp115-standalone-pinctrl"
|
||||
depending on the specific variant of the SoC being used.
|
||||
|
||||
Available mpp pins/groups and functions:
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required Properties:
|
|||
- compatible: Should be one of:
|
||||
- "mediatek,mt2701-apmixedsys"
|
||||
- "mediatek,mt2712-apmixedsys", "syscon"
|
||||
- "mediatek,mt6779-apmixedsys", "syscon"
|
||||
- "mediatek,mt6797-apmixedsys"
|
||||
- "mediatek,mt7622-apmixedsys"
|
||||
- "mediatek,mt7623-apmixedsys", "mediatek,mt2701-apmixedsys"
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ Required Properties:
|
|||
|
||||
- compatible: Should be one of:
|
||||
- "mediatek,mt2701-audsys", "syscon"
|
||||
- "mediatek,mt6779-audio", "syscon"
|
||||
- "mediatek,mt7622-audsys", "syscon"
|
||||
- "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon"
|
||||
- "mediatek,mt8183-audiosys", "syscon"
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ The MediaTek camsys controller provides various clocks to the system.
|
|||
Required Properties:
|
||||
|
||||
- compatible: Should be one of:
|
||||
- "mediatek,mt6779-camsys", "syscon"
|
||||
- "mediatek,mt8183-camsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required Properties:
|
|||
- compatible: Should be one of:
|
||||
- "mediatek,mt2701-imgsys", "syscon"
|
||||
- "mediatek,mt2712-imgsys", "syscon"
|
||||
- "mediatek,mt6779-imgsys", "syscon"
|
||||
- "mediatek,mt6797-imgsys", "syscon"
|
||||
- "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon"
|
||||
- "mediatek,mt8173-imgsys", "syscon"
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ Required Properties:
|
|||
- compatible: Should be one of:
|
||||
- "mediatek,mt2701-infracfg", "syscon"
|
||||
- "mediatek,mt2712-infracfg", "syscon"
|
||||
- "mediatek,mt6779-infracfg_ao", "syscon"
|
||||
- "mediatek,mt6797-infracfg", "syscon"
|
||||
- "mediatek,mt7622-infracfg", "syscon"
|
||||
- "mediatek,mt7623-infracfg", "mediatek,mt2701-infracfg", "syscon"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,22 @@
|
|||
Mediatek ipesys controller
|
||||
============================
|
||||
|
||||
The Mediatek ipesys controller provides various clocks to the system.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Should be one of:
|
||||
- "mediatek,mt6779-ipesys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
The ipesys controller uses the common clk binding from
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
|
||||
|
||||
Example:
|
||||
|
||||
ipesys: clock-controller@1b000000 {
|
||||
compatible = "mediatek,mt6779-ipesys", "syscon";
|
||||
reg = <0 0x1b000000 0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
|
@ -7,6 +7,7 @@ Required Properties:
|
|||
|
||||
- compatible: Should be one of:
|
||||
- "mediatek,mt2712-mfgcfg", "syscon"
|
||||
- "mediatek,mt6779-mfgcfg", "syscon"
|
||||
- "mediatek,mt8183-mfgcfg", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required Properties:
|
|||
- compatible: Should be one of:
|
||||
- "mediatek,mt2701-mmsys", "syscon"
|
||||
- "mediatek,mt2712-mmsys", "syscon"
|
||||
- "mediatek,mt6779-mmsys", "syscon"
|
||||
- "mediatek,mt6797-mmsys", "syscon"
|
||||
- "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon"
|
||||
- "mediatek,mt8173-mmsys", "syscon"
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@ Required Properties:
|
|||
- "mediatek,mt7629-pericfg", "syscon"
|
||||
- "mediatek,mt8135-pericfg", "syscon"
|
||||
- "mediatek,mt8173-pericfg", "syscon"
|
||||
- "mediatek,mt8183-pericfg", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
- #reset-cells: Must be 1
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required Properties:
|
|||
- compatible: Should be one of:
|
||||
- "mediatek,mt2701-topckgen"
|
||||
- "mediatek,mt2712-topckgen", "syscon"
|
||||
- "mediatek,mt6779-topckgen", "syscon"
|
||||
- "mediatek,mt6797-topckgen"
|
||||
- "mediatek,mt7622-topckgen"
|
||||
- "mediatek,mt7623-topckgen", "mediatek,mt2701-topckgen"
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required Properties:
|
|||
- compatible: Should be one of:
|
||||
- "mediatek,mt2701-vdecsys", "syscon"
|
||||
- "mediatek,mt2712-vdecsys", "syscon"
|
||||
- "mediatek,mt6779-vdecsys", "syscon"
|
||||
- "mediatek,mt6797-vdecsys", "syscon"
|
||||
- "mediatek,mt7623-vdecsys", "mediatek,mt2701-vdecsys", "syscon"
|
||||
- "mediatek,mt8173-vdecsys", "syscon"
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ Required Properties:
|
|||
|
||||
- compatible: Should be one of:
|
||||
- "mediatek,mt2712-vencsys", "syscon"
|
||||
- "mediatek,mt6779-vencsys", "syscon"
|
||||
- "mediatek,mt6797-vencsys", "syscon"
|
||||
- "mediatek,mt8173-vencsys", "syscon"
|
||||
- "mediatek,mt8183-vencsys", "syscon"
|
||||
|
|
|
|||
|
|
@ -1,22 +0,0 @@
|
|||
Realtek platforms device tree bindings
|
||||
--------------------------------------
|
||||
|
||||
|
||||
RTD1295 SoC
|
||||
===========
|
||||
|
||||
Required root node properties:
|
||||
|
||||
- compatible : must contain "realtek,rtd1295"
|
||||
|
||||
|
||||
Root node property compatible must contain, depending on board:
|
||||
|
||||
- MeLE V9: "mele,v9"
|
||||
- ProBox2 AVA: "probox2,ava"
|
||||
- Zidoo X9S: "zidoo,x9s"
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
compatible = "zidoo,x9s", "realtek,rtd1295";
|
||||
23
Documentation/devicetree/bindings/arm/realtek.yaml
Normal file
23
Documentation/devicetree/bindings/arm/realtek.yaml
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/realtek.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Realtek platforms device tree bindings
|
||||
|
||||
maintainers:
|
||||
- Andreas Färber <afaerber@suse.de>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
# RTD1295 SoC based boards
|
||||
items:
|
||||
- enum:
|
||||
- mele,v9
|
||||
- probox2,ava
|
||||
- zidoo,x9s
|
||||
- const: realtek,rtd1295
|
||||
...
|
||||
|
|
@ -45,7 +45,7 @@ Required properties when using sub-nodes:
|
|||
- #address-cells : number of cells to encode an address
|
||||
- #size-cells : number of cells representing the size of an address
|
||||
|
||||
For allwinner,sun8i-r40-ahci, the reset propertie must be present.
|
||||
For allwinner,sun8i-r40-ahci, the reset property must be present.
|
||||
|
||||
Sub-nodes required properties:
|
||||
- reg : the port number
|
||||
|
|
|
|||
|
|
@ -0,0 +1,85 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/bus/allwinner,sun50i-a64-de2.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Allwinner A64 Display Engine Bus Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
pattern: "^bus(@[0-9a-f]+)?$"
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 1
|
||||
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: allwinner,sun50i-a64-de2
|
||||
- items:
|
||||
- const: allwinner,sun50i-h6-de3
|
||||
- const: allwinner,sun50i-a64-de2
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
allwinner,sram:
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#definitions/phandle-array
|
||||
- maxItems: 1
|
||||
description:
|
||||
The SRAM that needs to be claimed to access the display engine
|
||||
bus.
|
||||
|
||||
ranges: true
|
||||
|
||||
patternProperties:
|
||||
# All other properties should be child nodes with unit-address and 'reg'
|
||||
"^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+$":
|
||||
type: object
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
- ranges
|
||||
- allwinner,sram
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
bus@1000000 {
|
||||
compatible = "allwinner,sun50i-a64-de2";
|
||||
reg = <0x1000000 0x400000>;
|
||||
allwinner,sram = <&de2_sram 1>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0x1000000 0x400000>;
|
||||
|
||||
display_clocks: clock@0 {
|
||||
compatible = "allwinner,sun50i-a64-de2-clk";
|
||||
reg = <0x0 0x100000>;
|
||||
clocks = <&ccu 52>, <&ccu 99>;
|
||||
clock-names = "bus", "mod";
|
||||
resets = <&ccu 30>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -71,7 +71,7 @@ Optional subnodes:
|
|||
|
||||
The following optional properties are properties that can be tagged onto
|
||||
any device subnode. We are assuming that there can be only ONE device per
|
||||
chipselect subnode, else the properties will become ambigous.
|
||||
chipselect subnode, else the properties will become ambiguous.
|
||||
|
||||
Optional properties arrays for SLOW chip selects:
|
||||
- qcom,xmem-recovery-cycles: recovery cycles is the time the memory continues to
|
||||
|
|
|
|||
|
|
@ -1,40 +0,0 @@
|
|||
Device tree bindings for Allwinner DE2/3 bus
|
||||
|
||||
The Allwinner A64 DE2 is on a special bus, which needs a SRAM region (SRAM C)
|
||||
to be claimed for enabling the access. The DE3 on Allwinner H6 is at the same
|
||||
situation, and the binding also applies.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be one of:
|
||||
- "allwinner,sun50i-a64-de2"
|
||||
- "allwinner,sun50i-h6-de3", "allwinner,sun50i-a64-de2"
|
||||
- reg: A resource specifier for the register space
|
||||
- #address-cells: Must be set to 1
|
||||
- #size-cells: Must be set to 1
|
||||
- ranges: Must be set up to map the address space inside the
|
||||
DE2, for the sub-blocks of DE2.
|
||||
- allwinner,sram: the SRAM that needs to be claimed
|
||||
|
||||
Example:
|
||||
|
||||
de2@1000000 {
|
||||
compatible = "allwinner,sun50i-a64-de2";
|
||||
reg = <0x1000000 0x400000>;
|
||||
allwinner,sram = <&de2_sram 1>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0x1000000 0x400000>;
|
||||
|
||||
display_clocks: clock@0 {
|
||||
compatible = "allwinner,sun50i-a64-de2-clk";
|
||||
reg = <0x0 0x100000>;
|
||||
clocks = <&ccu CLK_DE>,
|
||||
<&ccu CLK_BUS_DE>;
|
||||
clock-names = "mod",
|
||||
"bus";
|
||||
resets = <&ccu RST_BUS_DE>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -31,6 +31,7 @@ properties:
|
|||
- allwinner,sun8i-h3-ccu
|
||||
- allwinner,sun8i-h3-r-ccu
|
||||
- allwinner,sun8i-r40-ccu
|
||||
- allwinner,sun8i-v3-ccu
|
||||
- allwinner,sun8i-v3s-ccu
|
||||
- allwinner,sun9i-a80-ccu
|
||||
- allwinner,sun50i-a64-ccu
|
||||
|
|
|
|||
|
|
@ -12,7 +12,9 @@ clock generators, but a few (like the ARM or HDMI) will source from
|
|||
the PLL dividers directly.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "brcm,bcm2835-cprman"
|
||||
- compatible: should be one of the following,
|
||||
"brcm,bcm2711-cprman"
|
||||
"brcm,bcm2835-cprman"
|
||||
- #clock-cells: Should be <1>. The permitted clock-specifier values can be
|
||||
found in include/dt-bindings/clock/bcm2835.h
|
||||
- reg: Specifies base physical address and size of the registers
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ Required properties :
|
|||
"qcom,gcc-sdm630"
|
||||
"qcom,gcc-sdm660"
|
||||
"qcom,gcc-sdm845"
|
||||
"qcom,gcc-sm8150"
|
||||
|
||||
- reg : shall contain base register location and length
|
||||
- #clock-cells : shall contain 1
|
||||
|
|
@ -38,6 +39,13 @@ Documentation/devicetree/bindings/thermal/qcom-tsens.txt
|
|||
- protected-clocks : Protected clock specifier list as per common clock
|
||||
binding.
|
||||
|
||||
For SM8150 only:
|
||||
- clocks: a list of phandles and clock-specifier pairs,
|
||||
one for each entry in clock-names.
|
||||
- clock-names: "bi_tcxo" (required)
|
||||
"sleep_clk" (optional)
|
||||
"aud_ref_clock" (optional)
|
||||
|
||||
Example:
|
||||
clock-controller@900000 {
|
||||
compatible = "qcom,gcc-msm8960";
|
||||
|
|
@ -71,3 +79,16 @@ Example of GCC with protected-clocks properties:
|
|||
<GCC_LPASS_Q6_AXI_CLK>,
|
||||
<GCC_LPASS_SWAY_CLK>;
|
||||
};
|
||||
|
||||
Example of GCC with clocks
|
||||
gcc: clock-controller@100000 {
|
||||
compatible = "qcom,gcc-sm8150";
|
||||
reg = <0x00100000 0x1f0000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
clock-names = "bi_tcxo",
|
||||
"sleep_clk";
|
||||
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
|
||||
<&sleep_clk>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -6,9 +6,14 @@ some Qualcomm Technologies Inc. SoCs. It accepts clock requests from
|
|||
other hardware subsystems via RSC to control clocks.
|
||||
|
||||
Required properties :
|
||||
- compatible : shall contain "qcom,sdm845-rpmh-clk"
|
||||
- compatible : must be one of:
|
||||
"qcom,sdm845-rpmh-clk"
|
||||
"qcom,sm8150-rpmh-clk"
|
||||
|
||||
- #clock-cells : must contain 1
|
||||
- clocks: a list of phandles and clock-specifier pairs,
|
||||
one for each entry in clock-names.
|
||||
- clock-names: Parent board clock: "xo".
|
||||
|
||||
Example :
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,60 @@
|
|||
* Rockchip RK3308 Clock and Reset Unit
|
||||
|
||||
The RK3308 clock controller generates and supplies clock to various
|
||||
controllers within the SoC and also implements a reset controller for SoC
|
||||
peripherals.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: CRU should be "rockchip,rk3308-cru"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- #clock-cells: should be 1.
|
||||
- #reset-cells: should be 1.
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- rockchip,grf: phandle to the syscon managing the "general register files"
|
||||
If missing, pll rates are not changeable, due to the missing pll lock status.
|
||||
|
||||
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 the dt-bindings/clock/rk3308-cru.h headers and can be
|
||||
used in device tree sources. Similar macros exist for the reset sources in
|
||||
these files.
|
||||
|
||||
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:
|
||||
- "xin24m" - crystal input - required,
|
||||
- "xin32k" - rtc clock - optional,
|
||||
- "mclk_i2s0_8ch_in", "mclk_i2s1_8ch_in", "mclk_i2s2_8ch_in",
|
||||
"mclk_i2s3_8ch_in", "mclk_i2s0_2ch_in",
|
||||
"mclk_i2s1_2ch_in" - external I2S or SPDIF clock - optional,
|
||||
- "mac_clkin" - external MAC clock - optional
|
||||
|
||||
Example: Clock controller node:
|
||||
|
||||
cru: clock-controller@ff500000 {
|
||||
compatible = "rockchip,rk3308-cru";
|
||||
reg = <0x0 0xff500000 0x0 0x1000>;
|
||||
rockchip,grf = <&grf>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
Example: UART controller node that consumes the clock generated by the clock
|
||||
controller:
|
||||
|
||||
uart0: serial@ff0a0000 {
|
||||
compatible = "rockchip,rk3308-uart", "snps,dw-apb-uart";
|
||||
reg = <0x0 0xff0a0000 0x0 0x100>;
|
||||
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
|
||||
clock-names = "baudclk", "apb_pclk";
|
||||
reg-shift = <2>;
|
||||
reg-io-width = <4>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
@ -24,6 +24,8 @@ Required properties:
|
|||
Optional properties:
|
||||
- xtal-load-pf: Crystal load-capacitor value to fine-tune performance on a
|
||||
board, or to compensate for external influences.
|
||||
- vdd-supply: A regulator node for Vdd
|
||||
- vddout-supply: A regulator node for Vddout
|
||||
|
||||
For all PLL1, PLL2, ... an optional child node can be used to specify spread
|
||||
spectrum clocking parameters for a board.
|
||||
|
|
@ -41,6 +43,8 @@ Example:
|
|||
clocks = <&xtal_27Mhz>;
|
||||
#clock-cells = <1>;
|
||||
xtal-load-pf = <5>;
|
||||
vdd-supply = <&1v8-reg>;
|
||||
vddout-supply = <&3v3-reg>;
|
||||
/* PLL options to get SSC 1% centered */
|
||||
PLL2 {
|
||||
spread-spectrum = <4>;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,79 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/crypto/allwinner,sun4i-a10-crypto.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Allwinner A10 Security System Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: allwinner,sun4i-a10-crypto
|
||||
- items:
|
||||
- const: allwinner,sun5i-a13-crypto
|
||||
- const: allwinner,sun4i-a10-crypto
|
||||
- items:
|
||||
- const: allwinner,sun6i-a31-crypto
|
||||
- const: allwinner,sun4i-a10-crypto
|
||||
- items:
|
||||
- const: allwinner,sun7i-a20-crypto
|
||||
- const: allwinner,sun4i-a10-crypto
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Bus Clock
|
||||
- description: Module Clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: ahb
|
||||
- const: mod
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
reset-names:
|
||||
const: ahb
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: allwinner,sun6i-a31-crypto
|
||||
|
||||
then:
|
||||
required:
|
||||
- resets
|
||||
- reset-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
crypto: crypto-engine@1c15000 {
|
||||
compatible = "allwinner,sun4i-a10-crypto";
|
||||
reg = <0x01c15000 0x1000>;
|
||||
interrupts = <86>;
|
||||
clocks = <&ahb_gates 5>, <&ss_clk>;
|
||||
clock-names = "ahb", "mod";
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
* Allwinner Security System found on A20 SoC
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "allwinner,sun4i-a10-crypto".
|
||||
- reg: Should contain the Security System register location and length.
|
||||
- interrupts: Should contain the IRQ line for the Security System.
|
||||
- clocks : List of clock specifiers, corresponding to ahb and ss.
|
||||
- clock-names : Name of the functional clock, should be
|
||||
* "ahb" : AHB gating clock
|
||||
* "mod" : SS controller clock
|
||||
|
||||
Optional properties:
|
||||
- resets : phandle + reset specifier pair
|
||||
- reset-names : must contain "ahb"
|
||||
|
||||
Example:
|
||||
crypto: crypto-engine@1c15000 {
|
||||
compatible = "allwinner,sun4i-a10-crypto";
|
||||
reg = <0x01c15000 0x1000>;
|
||||
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&ahb_gates 5>, <&ss_clk>;
|
||||
clock-names = "ahb", "mod";
|
||||
};
|
||||
|
|
@ -1,119 +0,0 @@
|
|||
Amlogic specific extensions to the Synopsys Designware HDMI Controller
|
||||
======================================================================
|
||||
|
||||
The Amlogic Meson Synopsys Designware Integration is composed of :
|
||||
- A Synopsys DesignWare HDMI Controller IP
|
||||
- A TOP control block controlling the Clocks and PHY
|
||||
- A custom HDMI PHY in order to convert video to TMDS signal
|
||||
___________________________________
|
||||
| HDMI TOP |<= HPD
|
||||
|___________________________________|
|
||||
| | |
|
||||
| Synopsys HDMI | HDMI PHY |=> TMDS
|
||||
| Controller |________________|
|
||||
|___________________________________|<=> DDC
|
||||
|
||||
The HDMI TOP block only supports HPD sensing.
|
||||
The Synopsys HDMI Controller interrupt is routed through the
|
||||
TOP Block interrupt.
|
||||
Communication to the TOP Block and the Synopsys HDMI Controller is done
|
||||
via a pair of dedicated addr+read/write registers.
|
||||
The HDMI PHY is configured by registers in the HHI register block.
|
||||
|
||||
Pixel data arrives in 4:4:4 format from the VENC block and the VPU HDMI mux
|
||||
selects either the ENCI encoder for the 576i or 480i formats or the ENCP
|
||||
encoder for all the other formats including interlaced HD formats.
|
||||
|
||||
The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate
|
||||
DVI timings for the HDMI controller.
|
||||
|
||||
Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare
|
||||
HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
|
||||
audio source interfaces.
|
||||
|
||||
Required properties:
|
||||
- compatible: value should be different for each SoC family as :
|
||||
- GXBB (S905) : "amlogic,meson-gxbb-dw-hdmi"
|
||||
- GXL (S905X, S905D) : "amlogic,meson-gxl-dw-hdmi"
|
||||
- GXM (S912) : "amlogic,meson-gxm-dw-hdmi"
|
||||
followed by the common "amlogic,meson-gx-dw-hdmi"
|
||||
- G12A (S905X2, S905Y2, S905D2) : "amlogic,meson-g12a-dw-hdmi"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The HDMI interrupt number
|
||||
- clocks, clock-names : must have the phandles to the HDMI iahb and isfr clocks,
|
||||
and the Amlogic Meson venci clocks as described in
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt,
|
||||
the clocks are soc specific, the clock-names should be "iahb", "isfr", "venci"
|
||||
- resets, resets-names: must have the phandles to the HDMI apb, glue and phy
|
||||
resets as described in :
|
||||
Documentation/devicetree/bindings/reset/reset.txt,
|
||||
the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"
|
||||
|
||||
Optional properties:
|
||||
- hdmi-supply: Optional phandle to an external 5V regulator to power the HDMI
|
||||
logic, as described in the file ../regulator/regulator.txt
|
||||
|
||||
Required nodes:
|
||||
|
||||
The connections to the HDMI ports are modeled using the OF graph
|
||||
bindings specified in Documentation/devicetree/bindings/graph.txt.
|
||||
|
||||
The following table lists for each supported model the port number
|
||||
corresponding to each HDMI output and input.
|
||||
|
||||
Port 0 Port 1
|
||||
-----------------------------------------
|
||||
S905 (GXBB) VENC Input TMDS Output
|
||||
S905X (GXL) VENC Input TMDS Output
|
||||
S905D (GXL) VENC Input TMDS Output
|
||||
S912 (GXM) VENC Input TMDS Output
|
||||
S905X2 (G12A) VENC Input TMDS Output
|
||||
S905Y2 (G12A) VENC Input TMDS Output
|
||||
S905D2 (G12A) VENC Input TMDS Output
|
||||
|
||||
Example:
|
||||
|
||||
hdmi-connector {
|
||||
compatible = "hdmi-connector";
|
||||
type = "a";
|
||||
|
||||
port {
|
||||
hdmi_connector_in: endpoint {
|
||||
remote-endpoint = <&hdmi_tx_tmds_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
hdmi_tx: hdmi-tx@c883a000 {
|
||||
compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
|
||||
reg = <0x0 0xc883a000 0x0 0x1c>;
|
||||
interrupts = <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
|
||||
resets = <&reset RESET_HDMITX_CAPB3>,
|
||||
<&reset RESET_HDMI_SYSTEM_RESET>,
|
||||
<&reset RESET_HDMI_TX>;
|
||||
reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
|
||||
clocks = <&clkc CLKID_HDMI_PCLK>,
|
||||
<&clkc CLKID_CLK81>,
|
||||
<&clkc CLKID_GCLK_VENCI_INT0>;
|
||||
clock-names = "isfr", "iahb", "venci";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
/* VPU VENC Input */
|
||||
hdmi_tx_venc_port: port@0 {
|
||||
reg = <0>;
|
||||
|
||||
hdmi_tx_in: endpoint {
|
||||
remote-endpoint = <&hdmi_tx_out>;
|
||||
};
|
||||
};
|
||||
|
||||
/* TMDS Output */
|
||||
hdmi_tx_tmds_port: port@1 {
|
||||
reg = <1>;
|
||||
|
||||
hdmi_tx_tmds_out: endpoint {
|
||||
remote-endpoint = <&hdmi_connector_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,150 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
# Copyright 2019 BayLibre, SAS
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Amlogic specific extensions to the Synopsys Designware HDMI Controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
|
||||
description: |
|
||||
The Amlogic Meson Synopsys Designware Integration is composed of
|
||||
- A Synopsys DesignWare HDMI Controller IP
|
||||
- A TOP control block controlling the Clocks and PHY
|
||||
- A custom HDMI PHY in order to convert video to TMDS signal
|
||||
___________________________________
|
||||
| HDMI TOP |<= HPD
|
||||
|___________________________________|
|
||||
| | |
|
||||
| Synopsys HDMI | HDMI PHY |=> TMDS
|
||||
| Controller |________________|
|
||||
|___________________________________|<=> DDC
|
||||
|
||||
The HDMI TOP block only supports HPD sensing.
|
||||
The Synopsys HDMI Controller interrupt is routed through the
|
||||
TOP Block interrupt.
|
||||
Communication to the TOP Block and the Synopsys HDMI Controller is done
|
||||
via a pair of dedicated addr+read/write registers.
|
||||
The HDMI PHY is configured by registers in the HHI register block.
|
||||
|
||||
Pixel data arrives in "4:4:4" format from the VENC block and the VPU HDMI mux
|
||||
selects either the ENCI encoder for the 576i or 480i formats or the ENCP
|
||||
encoder for all the other formats including interlaced HD formats.
|
||||
|
||||
The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate
|
||||
DVI timings for the HDMI controller.
|
||||
|
||||
Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare
|
||||
HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
|
||||
audio source interfaces.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- amlogic,meson-gxbb-dw-hdmi # GXBB (S905)
|
||||
- amlogic,meson-gxl-dw-hdmi # GXL (S905X, S905D)
|
||||
- amlogic,meson-gxm-dw-hdmi # GXM (S912)
|
||||
- const: amlogic,meson-gx-dw-hdmi
|
||||
- enum:
|
||||
- amlogic,meson-g12a-dw-hdmi # G12A (S905X2, S905Y2, S905D2)
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
minItems: 3
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: isfr
|
||||
- const: iahb
|
||||
- const: venci
|
||||
|
||||
resets:
|
||||
minItems: 3
|
||||
|
||||
reset-names:
|
||||
items:
|
||||
- const: hdmitx_apb
|
||||
- const: hdmitx
|
||||
- const: hdmitx_phy
|
||||
|
||||
hdmi-supply:
|
||||
description: phandle to an external 5V regulator to power the HDMI logic
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/phandle
|
||||
|
||||
port@0:
|
||||
type: object
|
||||
description:
|
||||
A port node pointing to the VENC Input port node.
|
||||
|
||||
port@1:
|
||||
type: object
|
||||
description:
|
||||
A port node pointing to the TMDS Output port node.
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
"#sound-dai-cells":
|
||||
const: 0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
- resets
|
||||
- reset-names
|
||||
- port@0
|
||||
- port@1
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
hdmi_tx: hdmi-tx@c883a000 {
|
||||
compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
|
||||
reg = <0xc883a000 0x1c>;
|
||||
interrupts = <57>;
|
||||
resets = <&reset_apb>, <&reset_hdmitx>, <&reset_hdmitx_phy>;
|
||||
reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
|
||||
clocks = <&clk_isfr>, <&clk_iahb>, <&clk_venci>;
|
||||
clock-names = "isfr", "iahb", "venci";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
/* VPU VENC Input */
|
||||
hdmi_tx_venc_port: port@0 {
|
||||
reg = <0>;
|
||||
|
||||
hdmi_tx_in: endpoint {
|
||||
remote-endpoint = <&hdmi_tx_out>;
|
||||
};
|
||||
};
|
||||
|
||||
/* TMDS Output */
|
||||
hdmi_tx_tmds_port: port@1 {
|
||||
reg = <1>;
|
||||
|
||||
hdmi_tx_tmds_out: endpoint {
|
||||
remote-endpoint = <&hdmi_connector_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
|
|
@ -1,121 +0,0 @@
|
|||
Amlogic Meson Display Controller
|
||||
================================
|
||||
|
||||
The Amlogic Meson Display controller is composed of several components
|
||||
that are going to be documented below:
|
||||
|
||||
DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
|
||||
| vd1 _______ _____________ _________________ | |
|
||||
D |-------| |----| | | | | HDMI PLL |
|
||||
D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
|
||||
R |-------| |----| Processing | | | | |
|
||||
| osd2 | | | |---| Enci ----------|----|-----VDAC------|
|
||||
R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
|
||||
A | osd1 | | | Blenders | | Encl ----------|----|---------------|
|
||||
M |-------|______|----|____________| |________________| | |
|
||||
___|__________________________________________________________|_______________|
|
||||
|
||||
|
||||
VIU: Video Input Unit
|
||||
---------------------
|
||||
|
||||
The Video Input Unit is in charge of the pixel scanout from the DDR memory.
|
||||
It fetches the frames addresses, stride and parameters from the "Canvas" memory.
|
||||
This part is also in charge of the CSC (Colorspace Conversion).
|
||||
It can handle 2 OSD Planes and 2 Video Planes.
|
||||
|
||||
VPP: Video Post Processing
|
||||
--------------------------
|
||||
|
||||
The Video Post Processing is in charge of the scaling and blending of the
|
||||
various planes into a single pixel stream.
|
||||
There is a special "pre-blending" used by the video planes with a dedicated
|
||||
scaler and a "post-blending" to merge with the OSD Planes.
|
||||
The OSD planes also have a dedicated scaler for one of the OSD.
|
||||
|
||||
VENC: Video Encoders
|
||||
--------------------
|
||||
|
||||
The VENC is composed of the multiple pixel encoders :
|
||||
- ENCI : Interlace Video encoder for CVBS and Interlace HDMI
|
||||
- ENCP : Progressive Video Encoder for HDMI
|
||||
- ENCL : LCD LVDS Encoder
|
||||
The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
|
||||
tree and provides the scanout clock to the VPP and VIU.
|
||||
The ENCI is connected to a single VDAC for Composite Output.
|
||||
The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
|
||||
|
||||
Device Tree Bindings:
|
||||
---------------------
|
||||
|
||||
VPU: Video Processing Unit
|
||||
--------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: value should be different for each SoC family as :
|
||||
- GXBB (S905) : "amlogic,meson-gxbb-vpu"
|
||||
- GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
|
||||
- GXM (S912) : "amlogic,meson-gxm-vpu"
|
||||
followed by the common "amlogic,meson-gx-vpu"
|
||||
- G12A (S905X2, S905Y2, S905D2) : "amlogic,meson-g12a-vpu"
|
||||
- reg: base address and size of he following memory-mapped regions :
|
||||
- vpu
|
||||
- hhi
|
||||
- reg-names: should contain the names of the previous memory regions
|
||||
- interrupts: should contain the VENC Vsync interrupt number
|
||||
- amlogic,canvas: phandle to canvas provider node as described in the file
|
||||
../soc/amlogic/amlogic,canvas.txt
|
||||
|
||||
Optional properties:
|
||||
- power-domains: Optional phandle to associated power domain as described in
|
||||
the file ../power/power_domain.txt
|
||||
|
||||
Required nodes:
|
||||
|
||||
The connections to the VPU output video ports are modeled using the OF graph
|
||||
bindings specified in Documentation/devicetree/bindings/graph.txt.
|
||||
|
||||
The following table lists for each supported model the port number
|
||||
corresponding to each VPU output.
|
||||
|
||||
Port 0 Port 1
|
||||
-----------------------------------------
|
||||
S905 (GXBB) CVBS VDAC HDMI-TX
|
||||
S905X (GXL) CVBS VDAC HDMI-TX
|
||||
S905D (GXL) CVBS VDAC HDMI-TX
|
||||
S912 (GXM) CVBS VDAC HDMI-TX
|
||||
S905X2 (G12A) CVBS VDAC HDMI-TX
|
||||
S905Y2 (G12A) CVBS VDAC HDMI-TX
|
||||
S905D2 (G12A) CVBS VDAC HDMI-TX
|
||||
|
||||
Example:
|
||||
|
||||
tv-connector {
|
||||
compatible = "composite-video-connector";
|
||||
|
||||
port {
|
||||
tv_connector_in: endpoint {
|
||||
remote-endpoint = <&cvbs_vdac_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
vpu: vpu@d0100000 {
|
||||
compatible = "amlogic,meson-gxbb-vpu";
|
||||
reg = <0x0 0xd0100000 0x0 0x100000>,
|
||||
<0x0 0xc883c000 0x0 0x1000>,
|
||||
<0x0 0xc8838000 0x0 0x1000>;
|
||||
reg-names = "vpu", "hhi", "dmc";
|
||||
interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
/* CVBS VDAC output port */
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
cvbs_vdac_out: endpoint {
|
||||
remote-endpoint = <&tv_connector_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
137
Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
Normal file
137
Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
Normal file
|
|
@ -0,0 +1,137 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
# Copyright 2019 BayLibre, SAS
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Amlogic Meson Display Controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
|
||||
description: |
|
||||
The Amlogic Meson Display controller is composed of several components
|
||||
that are going to be documented below
|
||||
|
||||
DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
|
||||
| vd1 _______ _____________ _________________ | |
|
||||
D |-------| |----| | | | | HDMI PLL |
|
||||
D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
|
||||
R |-------| |----| Processing | | | | |
|
||||
| osd2 | | | |---| Enci ----------|----|-----VDAC------|
|
||||
R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
|
||||
A | osd1 | | | Blenders | | Encl ----------|----|---------------|
|
||||
M |-------|______|----|____________| |________________| | |
|
||||
___|__________________________________________________________|_______________|
|
||||
|
||||
|
||||
VIU: Video Input Unit
|
||||
---------------------
|
||||
|
||||
The Video Input Unit is in charge of the pixel scanout from the DDR memory.
|
||||
It fetches the frames addresses, stride and parameters from the "Canvas" memory.
|
||||
This part is also in charge of the CSC (Colorspace Conversion).
|
||||
It can handle 2 OSD Planes and 2 Video Planes.
|
||||
|
||||
VPP: Video Post Processing
|
||||
--------------------------
|
||||
|
||||
The Video Post Processing is in charge of the scaling and blending of the
|
||||
various planes into a single pixel stream.
|
||||
There is a special "pre-blending" used by the video planes with a dedicated
|
||||
scaler and a "post-blending" to merge with the OSD Planes.
|
||||
The OSD planes also have a dedicated scaler for one of the OSD.
|
||||
|
||||
VENC: Video Encoders
|
||||
--------------------
|
||||
|
||||
The VENC is composed of the multiple pixel encoders
|
||||
- ENCI : Interlace Video encoder for CVBS and Interlace HDMI
|
||||
- ENCP : Progressive Video Encoder for HDMI
|
||||
- ENCL : LCD LVDS Encoder
|
||||
The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
|
||||
tree and provides the scanout clock to the VPP and VIU.
|
||||
The ENCI is connected to a single VDAC for Composite Output.
|
||||
The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- amlogic,meson-gxbb-vpu # GXBB (S905)
|
||||
- amlogic,meson-gxl-vpu # GXL (S905X, S905D)
|
||||
- amlogic,meson-gxm-vpu # GXM (S912)
|
||||
- const: amlogic,meson-gx-vpu
|
||||
- enum:
|
||||
- amlogic,meson-g12a-vpu # G12A (S905X2, S905Y2, S905D2)
|
||||
|
||||
reg:
|
||||
maxItems: 2
|
||||
|
||||
reg-names:
|
||||
items:
|
||||
- const: vpu
|
||||
- const: hhi
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
description: phandle to the associated power domain
|
||||
|
||||
port@0:
|
||||
type: object
|
||||
description:
|
||||
A port node pointing to the CVBS VDAC port node.
|
||||
|
||||
port@1:
|
||||
type: object
|
||||
description:
|
||||
A port node pointing to the HDMI-TX port node.
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- port@0
|
||||
- port@1
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
|
||||
examples:
|
||||
- |
|
||||
vpu: vpu@d0100000 {
|
||||
compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
|
||||
reg = <0xd0100000 0x100000>, <0xc883c000 0x1000>;
|
||||
reg-names = "vpu", "hhi";
|
||||
interrupts = <3>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
/* CVBS VDAC output port */
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
cvbs_vdac_out: endpoint {
|
||||
remote-endpoint = <&tv_connector_in>;
|
||||
};
|
||||
};
|
||||
|
||||
/* HDMI TX output port */
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
hdmi_tx_out: endpoint {
|
||||
remote-endpoint = <&hdmi_tx_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -39,9 +39,11 @@ Required sub-nodes:
|
|||
|
||||
- port: describes LCD panel signals, following the common binding
|
||||
for video transmitter interfaces; see
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt;
|
||||
when it is a TFT panel, the port's endpoint must define the
|
||||
following property:
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||
|
||||
Deprecated properties:
|
||||
The port's endbpoint subnode had this, now deprecated property
|
||||
in the past. Drivers should be able to survive without it:
|
||||
|
||||
- arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values,
|
||||
defining the way CLD pads are wired up; first value
|
||||
|
|
@ -80,7 +82,6 @@ Example:
|
|||
port {
|
||||
clcd_pads: endpoint {
|
||||
remote-endpoint = <&clcd_panel>;
|
||||
arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -26,9 +26,8 @@ Optional properties:
|
|||
- clocks: phandle and clock specifier for each clock listed in
|
||||
the clock-names property
|
||||
- clock-names: "mclk"
|
||||
Describes SII902x MCLK input. MCLK is used to produce
|
||||
HDMI audio CTS values. This property is required if
|
||||
"#sound-dai-cells"-property is present. This property follows
|
||||
Describes SII902x MCLK input. MCLK can be used to produce
|
||||
HDMI audio CTS values. This property follows
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
consumer binding.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ Optional properties:
|
|||
- label: a symbolic name for the connector
|
||||
- hpd-gpios: HPD GPIO number
|
||||
- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing
|
||||
- ddc-en-gpios: signal to enable DDC bus
|
||||
|
||||
Required nodes:
|
||||
- Video port for HDMI input
|
||||
|
|
|
|||
|
|
@ -1,26 +0,0 @@
|
|||
Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "ampire,am-480272h3tmqw-t01h"
|
||||
|
||||
Optional properties:
|
||||
- power-supply: regulator to provide the supply voltage
|
||||
- enable-gpios: GPIO pin to enable or disable the panel
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
|
||||
Optional nodes:
|
||||
- Video port for RGB input.
|
||||
|
||||
Example:
|
||||
panel_rgb: panel-rgb {
|
||||
compatible = "ampire,am-480272h3tmqw-t01h";
|
||||
enable-gpios = <&gpioa 8 1>;
|
||||
port {
|
||||
panel_in_rgb: endpoint {
|
||||
remote-endpoint = <&controller_out_rgb>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/ampire,am-480272h3tmqw-t01h.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
|
||||
|
||||
maintainers:
|
||||
- Yannick Fertre <yannick.fertre@st.com>
|
||||
- Thierry Reding <treding@nvidia.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: ampire,am-480272h3tmqw-t01h
|
||||
|
||||
power-supply: true
|
||||
enable-gpios: true
|
||||
backlight: true
|
||||
port: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
panel_rgb: panel {
|
||||
compatible = "ampire,am-480272h3tmqw-t01h";
|
||||
enable-gpios = <&gpioa 8 1>;
|
||||
port {
|
||||
panel_in_rgb: endpoint {
|
||||
remote-endpoint = <&controller_out_rgb>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -10,7 +10,7 @@ Required properties:
|
|||
- compatible: should be "arm,versatile-tft-panel"
|
||||
|
||||
Required subnodes:
|
||||
- port: see display/panel/panel-common.txt, graph.txt
|
||||
- port: see display/panel/panel-common.yaml, graph.txt
|
||||
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -1,9 +0,0 @@
|
|||
Armadeus ST0700 Adapt. A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with
|
||||
an adapter board.
|
||||
|
||||
Required properties:
|
||||
- compatible: "armadeus,st0700-adapt"
|
||||
- power-supply: see panel-common.txt
|
||||
|
||||
Optional properties:
|
||||
- backlight: see panel-common.txt
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/armadeus,st0700-adapt.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Armadeus ST0700 Adapter
|
||||
|
||||
description:
|
||||
A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with an adapter board.
|
||||
|
||||
maintainers:
|
||||
- '"Sébastien Szymanski" <sebastien.szymanski@armadeus.com>'
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: armadeus,st0700-adapt
|
||||
|
||||
power-supply: true
|
||||
backlight: true
|
||||
port: true
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- power-supply
|
||||
|
||||
...
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "bananapi,s070wv20-ct16"
|
||||
- power-supply: see ./panel-common.txt
|
||||
|
||||
Optional properties:
|
||||
- enable-gpios: see ./simple-panel.txt
|
||||
- backlight: see ./simple-panel.txt
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in ./simple-panel.txt.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/bananapi,s070wv20-ct16.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: bananapi,s070wv20-ct16
|
||||
|
||||
power-supply: true
|
||||
backlight: true
|
||||
enable-gpios: true
|
||||
port: true
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- power-supply
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
Boe Himax8279d 1200x1920 TFT LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p"
|
||||
- reg: DSI virtual channel of the peripheral
|
||||
- enable-gpios: panel enable gpio
|
||||
- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply voltage
|
||||
- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply voltage
|
||||
|
||||
Optional properties:
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
|
||||
Example:
|
||||
|
||||
&mipi_dsi {
|
||||
panel {
|
||||
compatible = "boe,himax8279d8p", "boe,himax8279d10p";
|
||||
reg = <0>;
|
||||
backlight = <&backlight>;
|
||||
enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
|
||||
pp33-gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
|
||||
pp18-gpios = <&gpio 36 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "dlc,dlc0700yzg-1"
|
||||
- power-supply: See simple-panel.txt
|
||||
|
||||
Optional properties:
|
||||
- reset-gpios: See panel-common.txt
|
||||
- enable-gpios: See simple-panel.txt
|
||||
- backlight: See simple-panel.txt
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/dlc,dlc0700yzg-1.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel
|
||||
|
||||
maintainers:
|
||||
- Philipp Zabel <p.zabel@pengutronix.de>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: dlc,dlc0700yzg-1
|
||||
|
||||
reset-gpios: true
|
||||
enable-gpios: true
|
||||
backlight: true
|
||||
port: true
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- power-supply
|
||||
|
||||
...
|
||||
|
|
@ -40,7 +40,7 @@ simple-panel.txt
|
|||
| Identifier | compatbile | description |
|
||||
+=================+=====================+=====================================+
|
||||
| ETM0700G0DH6 | edt,etm070080dh6 | WVGA TFT Display with capacitive |
|
||||
| | | Touchscreen |
|
||||
| | edt,etm0700g0dh6 | Touchscreen |
|
||||
+-----------------+---------------------+-------------------------------------+
|
||||
| ETM0700G0BDH6 | edt,etm070080bdh6 | Same as ETM0700G0DH6 but with |
|
||||
| | | inverted pixel clock. |
|
||||
|
|
|
|||
|
|
@ -0,0 +1,12 @@
|
|||
GiantPlus 3.0" (320x240 pixels) 24-bit TFT LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "giantplus,gpm940b0"
|
||||
- power-supply: as specified in the base binding
|
||||
|
||||
Optional properties:
|
||||
- backlight: as specified in the base binding
|
||||
- enable-gpios: as specified in the base binding
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "innolux,ee101ia-01d"
|
||||
|
||||
This binding is compatible with the lvds-panel binding, which is specified
|
||||
in panel-lvds.txt in this directory.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/innolux,ee101ia-01d.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
|
||||
|
||||
maintainers:
|
||||
- Heiko Stuebner <heiko.stuebner@bq.com>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: lvds.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: innolux,ee101ia-01d
|
||||
- {} # panel-lvds, but not listed here to avoid false select
|
||||
|
||||
backlight: true
|
||||
enable-gpios: true
|
||||
power-supply: true
|
||||
width-mm: true
|
||||
height-mm: true
|
||||
panel-timing: true
|
||||
port: true
|
||||
|
||||
additionalProperties: false
|
||||
...
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "kingdisplay,kd035g6-54nt"
|
||||
- power-supply: See panel-common.txt
|
||||
- reset-gpios: See panel-common.txt
|
||||
|
||||
Optional properties:
|
||||
- backlight: see panel-common.txt
|
||||
|
||||
The generic bindings for the SPI slaves documented in [1] also apply.
|
||||
|
||||
The device node can contain one 'port' child node with one child
|
||||
'endpoint' node, according to the bindings defined in [2]. This
|
||||
node should describe panel's video bus.
|
||||
|
||||
[1]: Documentation/devicetree/bindings/spi/spi-bus.txt
|
||||
[2]: Documentation/devicetree/bindings/graph.txt
|
||||
|
||||
Example:
|
||||
|
||||
&spi {
|
||||
panel@0 {
|
||||
compatible = "kingdisplay,kd035g6-54nt";
|
||||
reg = <0>;
|
||||
|
||||
spi-max-frequency = <3125000>;
|
||||
spi-3wire;
|
||||
spi-cs-high;
|
||||
|
||||
reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
|
||||
|
||||
backlight = <&backlight>;
|
||||
power-supply = <&ldo6>;
|
||||
|
||||
port {
|
||||
panel_input: endpoint {
|
||||
remote-endpoint = <&panel_output>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
107
Documentation/devicetree/bindings/display/panel/lvds.yaml
Normal file
107
Documentation/devicetree/bindings/display/panel/lvds.yaml
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/lvds.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: LVDS Display Panel
|
||||
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
description: |+
|
||||
LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
|
||||
incompatible data link layers have been used over time to transmit image data
|
||||
to LVDS panels. This bindings supports display panels compatible with the
|
||||
following specifications.
|
||||
|
||||
[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
|
||||
1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
|
||||
[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
|
||||
Semiconductor
|
||||
[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
|
||||
Electronics Standards Association (VESA)
|
||||
|
||||
Device compatible with those specifications have been marketed under the
|
||||
FPD-Link and FlatLink brands.
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: panel-lvds
|
||||
description:
|
||||
Shall contain "panel-lvds" in addition to a mandatory panel-specific
|
||||
compatible string defined in individual panel bindings. The "panel-lvds"
|
||||
value shall never be used on its own.
|
||||
|
||||
data-mapping:
|
||||
enum:
|
||||
- jeida-18
|
||||
- jeida-24
|
||||
- vesa-24
|
||||
description: |
|
||||
The color signals mapping order.
|
||||
|
||||
LVDS data mappings are defined as follows.
|
||||
|
||||
- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
|
||||
[VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
|
||||
|
||||
Slot 0 1 2 3 4 5 6
|
||||
________________ _________________
|
||||
Clock \_______________________/
|
||||
______ ______ ______ ______ ______ ______ ______
|
||||
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
|
||||
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
|
||||
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
|
||||
|
||||
- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
|
||||
specifications. Data are transferred as follows on 4 LVDS lanes.
|
||||
|
||||
Slot 0 1 2 3 4 5 6
|
||||
________________ _________________
|
||||
Clock \_______________________/
|
||||
______ ______ ______ ______ ______ ______ ______
|
||||
DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
|
||||
DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
|
||||
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
|
||||
DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
|
||||
|
||||
- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
|
||||
Data are transferred as follows on 4 LVDS lanes.
|
||||
|
||||
Slot 0 1 2 3 4 5 6
|
||||
________________ _________________
|
||||
Clock \_______________________/
|
||||
______ ______ ______ ______ ______ ______ ______
|
||||
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
|
||||
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
|
||||
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
|
||||
DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
|
||||
|
||||
Control signals are mapped as follows.
|
||||
|
||||
CTL0: HSync
|
||||
CTL1: VSync
|
||||
CTL2: Data Enable
|
||||
CTL3: 0
|
||||
|
||||
data-mirror:
|
||||
type: boolean
|
||||
description:
|
||||
If set, reverse the bit order described in the data mappings below on all
|
||||
data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- data-mapping
|
||||
- width-mm
|
||||
- height-mm
|
||||
- panel-timing
|
||||
- port
|
||||
|
||||
...
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
Mitsubishi AA204XD12 LVDS Display Panel
|
||||
=======================================
|
||||
|
||||
The AA104XD12 is a 10.4" XGA TFT-LCD display panel.
|
||||
|
||||
These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
|
||||
with the following device-specific properties.
|
||||
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that
|
||||
order.
|
||||
- vcc-supply: Reference to the regulator powering the panel VCC pins.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
panel {
|
||||
compatible = "mitsubishi,aa104xd12", "panel-lvds";
|
||||
vcc-supply = <&vcc_3v3>;
|
||||
|
||||
width-mm = <210>;
|
||||
height-mm = <158>;
|
||||
|
||||
data-mapping = "jeida-24";
|
||||
|
||||
panel-timing {
|
||||
/* 1024x768 @65Hz */
|
||||
clock-frequency = <65000000>;
|
||||
hactive = <1024>;
|
||||
vactive = <768>;
|
||||
hsync-len = <136>;
|
||||
hfront-porch = <20>;
|
||||
hback-porch = <160>;
|
||||
vfront-porch = <3>;
|
||||
vback-porch = <29>;
|
||||
vsync-len = <6>;
|
||||
};
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&lvds_encoder>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa104xd12.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Mitsubishi AA104XD12 10.4" XGA LVDS Display Panel
|
||||
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: lvds.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: mitsubishi,aa104xd12
|
||||
- {} # panel-lvds, but not listed here to avoid false select
|
||||
|
||||
vcc-supply:
|
||||
description: Reference to the regulator powering the panel VCC pins.
|
||||
|
||||
data-mapping:
|
||||
const: jeida-24
|
||||
|
||||
width-mm:
|
||||
const: 210
|
||||
|
||||
height-mm:
|
||||
const: 158
|
||||
|
||||
panel-timing: true
|
||||
port: true
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- vcc-supply
|
||||
|
||||
examples:
|
||||
- |+
|
||||
|
||||
panel {
|
||||
compatible = "mitsubishi,aa104xd12", "panel-lvds";
|
||||
vcc-supply = <&vcc_3v3>;
|
||||
|
||||
width-mm = <210>;
|
||||
height-mm = <158>;
|
||||
|
||||
data-mapping = "jeida-24";
|
||||
|
||||
panel-timing {
|
||||
/* 1024x768 @65Hz */
|
||||
clock-frequency = <65000000>;
|
||||
hactive = <1024>;
|
||||
vactive = <768>;
|
||||
hsync-len = <136>;
|
||||
hfront-porch = <20>;
|
||||
hback-porch = <160>;
|
||||
vfront-porch = <3>;
|
||||
vback-porch = <29>;
|
||||
vsync-len = <6>;
|
||||
};
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&lvds_encoder>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
Mitsubishi AA121TD01 LVDS Display Panel
|
||||
=======================================
|
||||
|
||||
The AA121TD01 is a 12.1" WXGA TFT-LCD display panel.
|
||||
|
||||
These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
|
||||
with the following device-specific properties.
|
||||
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that
|
||||
order.
|
||||
- vcc-supply: Reference to the regulator powering the panel VCC pins.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
panel {
|
||||
compatible = "mitsubishi,aa121td01", "panel-lvds";
|
||||
vcc-supply = <&vcc_3v3>;
|
||||
|
||||
width-mm = <261>;
|
||||
height-mm = <163>;
|
||||
|
||||
data-mapping = "jeida-24";
|
||||
|
||||
panel-timing {
|
||||
/* 1280x800 @60Hz */
|
||||
clock-frequency = <71000000>;
|
||||
hactive = <1280>;
|
||||
vactive = <800>;
|
||||
hsync-len = <70>;
|
||||
hfront-porch = <20>;
|
||||
hback-porch = <70>;
|
||||
vsync-len = <5>;
|
||||
vfront-porch = <3>;
|
||||
vback-porch = <15>;
|
||||
};
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&lvds_encoder>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa121td01.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Mitsubishi AA121TD01 12.1" WXGA LVDS Display Panel
|
||||
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: lvds.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: mitsubishi,aa121td01
|
||||
- {} # panel-lvds, but not listed here to avoid false select
|
||||
|
||||
vcc-supply:
|
||||
description: Reference to the regulator powering the panel VCC pins.
|
||||
|
||||
data-mapping:
|
||||
const: jeida-24
|
||||
|
||||
width-mm:
|
||||
const: 261
|
||||
|
||||
height-mm:
|
||||
const: 163
|
||||
|
||||
panel-timing: true
|
||||
port: true
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- vcc-supply
|
||||
|
||||
examples:
|
||||
- |+
|
||||
panel {
|
||||
compatible = "mitsubishi,aa121td01", "panel-lvds";
|
||||
vcc-supply = <&vcc_3v3>;
|
||||
|
||||
width-mm = <261>;
|
||||
height-mm = <163>;
|
||||
|
||||
data-mapping = "jeida-24";
|
||||
|
||||
panel-timing {
|
||||
/* 1280x800 @60Hz */
|
||||
clock-frequency = <71000000>;
|
||||
hactive = <1280>;
|
||||
vactive = <800>;
|
||||
hsync-len = <70>;
|
||||
hfront-porch = <20>;
|
||||
hback-porch = <70>;
|
||||
vsync-len = <5>;
|
||||
vfront-porch = <3>;
|
||||
vback-porch = <15>;
|
||||
};
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&lvds_encoder>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/nec,nl8048hl11.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NEC NL8048HL11 4.1" WVGA TFT LCD panel
|
||||
|
||||
description:
|
||||
The NEC NL8048HL11 is a 4.1" WVGA TFT LCD panel with a 24-bit RGB parallel
|
||||
data interface and an SPI control interface.
|
||||
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: nec,nl8048hl11
|
||||
|
||||
label: true
|
||||
port: true
|
||||
reg: true
|
||||
reset-gpios: true
|
||||
|
||||
spi-max-frequency:
|
||||
maximum: 10000000
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- reset-gpios
|
||||
- port
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
spi0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
lcd_panel: panel@0 {
|
||||
compatible = "nec,nl8048hl11";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <10000000>;
|
||||
|
||||
reset-gpios = <&gpio7 7 GPIO_ACTIVE_LOW>;
|
||||
|
||||
port {
|
||||
lcd_in: endpoint {
|
||||
remote-endpoint = <&dpi_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
OrtusTech COM37H3M05DTC Blanview 3.7" VGA portrait TFT-LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "ortustech,com37h3m05dtc"
|
||||
|
||||
Optional properties:
|
||||
- enable-gpios: GPIO pin to enable or disable the panel
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
- power-supply: phandle of the regulator that provides the supply voltage
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
OrtusTech COM37H3M99DTC Blanview 3.7" VGA portrait TFT-LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "ortustech,com37h3m99dtc"
|
||||
|
||||
Optional properties:
|
||||
- enable-gpios: GPIO pin to enable or disable the panel
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
- power-supply: phandle of the regulator that provides the supply voltage
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
|
@ -1,101 +0,0 @@
|
|||
Common Properties for Display Panel
|
||||
===================================
|
||||
|
||||
This document defines device tree properties common to several classes of
|
||||
display panels. It doesn't constitue a device tree binding specification by
|
||||
itself but is meant to be referenced by device tree bindings.
|
||||
|
||||
When referenced from panel device tree bindings the properties defined in this
|
||||
document are defined as follows. The panel device tree bindings are
|
||||
responsible for defining whether each property is required or optional.
|
||||
|
||||
|
||||
Descriptive Properties
|
||||
----------------------
|
||||
|
||||
- width-mm,
|
||||
- height-mm: The width-mm and height-mm specify the width and height of the
|
||||
physical area where images are displayed. These properties are expressed in
|
||||
millimeters and rounded to the closest unit.
|
||||
|
||||
- label: The label property specifies a symbolic name for the panel as a
|
||||
string suitable for use by humans. It typically contains a name inscribed on
|
||||
the system (e.g. as an affixed label) or specified in the system's
|
||||
documentation (e.g. in the user's manual).
|
||||
|
||||
If no such name exists, and unless the property is mandatory according to
|
||||
device tree bindings, it shall rather be omitted than constructed of
|
||||
non-descriptive information. For instance an LCD panel in a system that
|
||||
contains a single panel shall not be labelled "LCD" if that name is not
|
||||
inscribed on the system or used in a descriptive fashion in system
|
||||
documentation.
|
||||
|
||||
|
||||
Display Timings
|
||||
---------------
|
||||
|
||||
- panel-timing: Most display panels are restricted to a single resolution and
|
||||
require specific display timings. The panel-timing subnode expresses those
|
||||
timings as specified in the timing subnode section of the display timing
|
||||
bindings defined in
|
||||
Documentation/devicetree/bindings/display/panel/display-timing.txt.
|
||||
|
||||
|
||||
Connectivity
|
||||
------------
|
||||
|
||||
- ports: Panels receive video data through one or multiple connections. While
|
||||
the nature of those connections is specific to the panel type, the
|
||||
connectivity is expressed in a standard fashion using ports as specified in
|
||||
the device graph bindings defined in
|
||||
Documentation/devicetree/bindings/graph.txt.
|
||||
|
||||
- ddc-i2c-bus: Some panels expose EDID information through an I2C-compatible
|
||||
bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
|
||||
phandle to the system I2C controller connected to that bus.
|
||||
|
||||
|
||||
Control I/Os
|
||||
------------
|
||||
|
||||
Many display panels can be controlled through pins driven by GPIOs. The nature
|
||||
and timing of those control signals are device-specific and left for panel
|
||||
device tree bindings to specify. The following GPIO specifiers can however be
|
||||
used for panels that implement compatible control signals.
|
||||
|
||||
- enable-gpios: Specifier for a GPIO connected to the panel enable control
|
||||
signal. The enable signal is active high and enables operation of the panel.
|
||||
This property can also be used for panels implementing an active low power
|
||||
down signal, which is a negated version of the enable signal. Active low
|
||||
enable signals (or active high power down signals) can be supported by
|
||||
inverting the GPIO specifier polarity flag.
|
||||
|
||||
Note that the enable signal control panel operation only and must not be
|
||||
confused with a backlight enable signal.
|
||||
|
||||
- reset-gpios: Specifier for a GPIO coonnected to the panel reset control
|
||||
signal. The reset signal is active low and resets the panel internal logic
|
||||
while active. Active high reset signals can be supported by inverting the
|
||||
GPIO specifier polarity flag.
|
||||
|
||||
Power
|
||||
-----
|
||||
|
||||
- power-supply: display panels require power to be supplied. While several
|
||||
panels need more than one power supply with panel-specific constraints
|
||||
governing the order and timings of the power supplies, in many cases a single
|
||||
power supply is sufficient, either because the panel has a single power rail,
|
||||
or because all its power rails can be driven by the same supply. In that case
|
||||
the power-supply property specifies the supply powering the panel as a phandle
|
||||
to a regulator.
|
||||
|
||||
Backlight
|
||||
---------
|
||||
|
||||
Most display panels include a backlight. Some of them also include a backlight
|
||||
controller exposed through a control bus such as I2C or DSI. Others expose
|
||||
backlight control through GPIO, PWM or other signals connected to an external
|
||||
backlight controller.
|
||||
|
||||
- backlight: For panels whose backlight is controlled by an external backlight
|
||||
controller, this property contains a phandle that references the controller.
|
||||
|
|
@ -0,0 +1,149 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/panel-common.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Common Properties for Display Panels
|
||||
|
||||
maintainers:
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
||||
|
||||
description: |
|
||||
This document defines device tree properties common to several classes of
|
||||
display panels. It doesn't constitue a device tree binding specification by
|
||||
itself but is meant to be referenced by device tree bindings.
|
||||
|
||||
When referenced from panel device tree bindings the properties defined in this
|
||||
document are defined as follows. The panel device tree bindings are
|
||||
responsible for defining whether each property is required or optional.
|
||||
|
||||
properties:
|
||||
# Descriptive Properties
|
||||
width-mm:
|
||||
description:
|
||||
Specifies the width of the physical area where images are displayed. This
|
||||
property is expressed in millimeters and rounded to the closest unit.
|
||||
|
||||
height-mm:
|
||||
description:
|
||||
Specifies the height of the physical area where images are displayed. This
|
||||
property is expressed in millimeters and rounded to the closest unit.
|
||||
|
||||
label:
|
||||
description: |
|
||||
The label property specifies a symbolic name for the panel as a
|
||||
string suitable for use by humans. It typically contains a name inscribed
|
||||
on the system (e.g. as an affixed label) or specified in the system's
|
||||
documentation (e.g. in the user's manual).
|
||||
|
||||
If no such name exists, and unless the property is mandatory according to
|
||||
device tree bindings, it shall rather be omitted than constructed of
|
||||
non-descriptive information. For instance an LCD panel in a system that
|
||||
contains a single panel shall not be labelled "LCD" if that name is not
|
||||
inscribed on the system or used in a descriptive fashion in system
|
||||
documentation.
|
||||
|
||||
rotation:
|
||||
description:
|
||||
Display rotation in degrees counter clockwise (0,90,180,270)
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- enum: [ 0, 90, 180, 270 ]
|
||||
|
||||
# Display Timings
|
||||
panel-timing:
|
||||
type: object
|
||||
description:
|
||||
Most display panels are restricted to a single resolution and
|
||||
require specific display timings. The panel-timing subnode expresses those
|
||||
timings as specified in the timing subnode section of the display timing
|
||||
bindings defined in
|
||||
Documentation/devicetree/bindings/display/panel/display-timing.txt.
|
||||
|
||||
# Connectivity
|
||||
port:
|
||||
type: object
|
||||
|
||||
ports:
|
||||
type: object
|
||||
description:
|
||||
Panels receive video data through one or multiple connections. While
|
||||
the nature of those connections is specific to the panel type, the
|
||||
connectivity is expressed in a standard fashion using ports as specified
|
||||
in the device graph bindings defined in
|
||||
Documentation/devicetree/bindings/graph.txt.
|
||||
|
||||
ddc-i2c-bus:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Some panels expose EDID information through an I2C-compatible
|
||||
bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
|
||||
phandle to the system I2C controller connected to that bus.
|
||||
|
||||
no-hpd:
|
||||
type: boolean
|
||||
description:
|
||||
This panel is supposed to communicate that it's ready via HPD
|
||||
(hot plug detect) signal, but the signal isn't hooked up so we should
|
||||
hardcode the max delay from the panel spec when powering up the panel.
|
||||
|
||||
# Control I/Os
|
||||
|
||||
# Many display panels can be controlled through pins driven by GPIOs. The nature
|
||||
# and timing of those control signals are device-specific and left for panel
|
||||
# device tree bindings to specify. The following GPIO specifiers can however be
|
||||
# used for panels that implement compatible control signals.
|
||||
|
||||
enable-gpios:
|
||||
maxItems: 1
|
||||
description: |
|
||||
Specifier for a GPIO connected to the panel enable control signal. The
|
||||
enable signal is active high and enables operation of the panel. This
|
||||
property can also be used for panels implementing an active low power down
|
||||
signal, which is a negated version of the enable signal. Active low enable
|
||||
signals (or active high power down signals) can be supported by inverting
|
||||
the GPIO specifier polarity flag.
|
||||
|
||||
Note that the enable signal control panel operation only and must not be
|
||||
confused with a backlight enable signal.
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
description:
|
||||
Specifier for a GPIO connected to the panel reset control signal.
|
||||
The reset signal is active low and resets the panel internal logic
|
||||
while active. Active high reset signals can be supported by inverting the
|
||||
GPIO specifier polarity flag.
|
||||
|
||||
# Power
|
||||
power-supply:
|
||||
description:
|
||||
Display panels require power to be supplied. While several panels need
|
||||
more than one power supply with panel-specific constraints governing the
|
||||
order and timings of the power supplies, in many cases a single power
|
||||
supply is sufficient, either because the panel has a single power rail, or
|
||||
because all its power rails can be driven by the same supply. In that case
|
||||
the power-supply property specifies the supply powering the panel as a
|
||||
phandle to a regulator.
|
||||
|
||||
# Backlight
|
||||
|
||||
# Most display panels include a backlight. Some of them also include a backlight
|
||||
# controller exposed through a control bus such as I2C or DSI. Others expose
|
||||
# backlight control through GPIO, PWM or other signals connected to an external
|
||||
# backlight controller.
|
||||
|
||||
backlight:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
For panels whose backlight is controlled by an external backlight
|
||||
controller, this property contains a phandle that references the
|
||||
controller.
|
||||
|
||||
dependencies:
|
||||
width-mm: [ height-mm ]
|
||||
height-mm: [ width-mm ]
|
||||
|
||||
...
|
||||
|
|
@ -1,121 +0,0 @@
|
|||
LVDS Display Panel
|
||||
==================
|
||||
|
||||
LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
|
||||
incompatible data link layers have been used over time to transmit image data
|
||||
to LVDS panels. This bindings supports display panels compatible with the
|
||||
following specifications.
|
||||
|
||||
[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
|
||||
1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
|
||||
[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
|
||||
Semiconductor
|
||||
[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
|
||||
Electronics Standards Association (VESA)
|
||||
|
||||
Device compatible with those specifications have been marketed under the
|
||||
FPD-Link and FlatLink brands.
|
||||
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Shall contain "panel-lvds" in addition to a mandatory
|
||||
panel-specific compatible string defined in individual panel bindings. The
|
||||
"panel-lvds" value shall never be used on its own.
|
||||
- width-mm: See panel-common.txt.
|
||||
- height-mm: See panel-common.txt.
|
||||
- data-mapping: The color signals mapping order, "jeida-18", "jeida-24"
|
||||
or "vesa-24".
|
||||
|
||||
Optional properties:
|
||||
|
||||
- label: See panel-common.txt.
|
||||
- gpios: See panel-common.txt.
|
||||
- backlight: See panel-common.txt.
|
||||
- power-supply: See panel-common.txt.
|
||||
- data-mirror: If set, reverse the bit order described in the data mappings
|
||||
below on all data lanes, transmitting bits for slots 6 to 0 instead of
|
||||
0 to 6.
|
||||
|
||||
Required nodes:
|
||||
|
||||
- panel-timing: See panel-common.txt.
|
||||
- ports: See panel-common.txt. These bindings require a single port subnode
|
||||
corresponding to the panel LVDS input.
|
||||
|
||||
|
||||
LVDS data mappings are defined as follows.
|
||||
|
||||
- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
|
||||
[VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
|
||||
|
||||
Slot 0 1 2 3 4 5 6
|
||||
________________ _________________
|
||||
Clock \_______________________/
|
||||
______ ______ ______ ______ ______ ______ ______
|
||||
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
|
||||
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
|
||||
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
|
||||
|
||||
- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
|
||||
specifications. Data are transferred as follows on 4 LVDS lanes.
|
||||
|
||||
Slot 0 1 2 3 4 5 6
|
||||
________________ _________________
|
||||
Clock \_______________________/
|
||||
______ ______ ______ ______ ______ ______ ______
|
||||
DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
|
||||
DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
|
||||
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
|
||||
DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
|
||||
|
||||
- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
|
||||
Data are transferred as follows on 4 LVDS lanes.
|
||||
|
||||
Slot 0 1 2 3 4 5 6
|
||||
________________ _________________
|
||||
Clock \_______________________/
|
||||
______ ______ ______ ______ ______ ______ ______
|
||||
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
|
||||
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
|
||||
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
|
||||
DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
|
||||
|
||||
Control signals are mapped as follows.
|
||||
|
||||
CTL0: HSync
|
||||
CTL1: VSync
|
||||
CTL2: Data Enable
|
||||
CTL3: 0
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
panel {
|
||||
compatible = "mitsubishi,aa121td01", "panel-lvds";
|
||||
|
||||
width-mm = <261>;
|
||||
height-mm = <163>;
|
||||
|
||||
data-mapping = "jeida-24";
|
||||
|
||||
panel-timing {
|
||||
/* 1280x800 @60Hz */
|
||||
clock-frequency = <71000000>;
|
||||
hactive = <1280>;
|
||||
vactive = <800>;
|
||||
hsync-len = <70>;
|
||||
hfront-porch = <20>;
|
||||
hback-porch = <70>;
|
||||
vsync-len = <5>;
|
||||
vfront-porch = <3>;
|
||||
vback-porch = <15>;
|
||||
};
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&lvds_encoder>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Common display properties
|
||||
-------------------------
|
||||
|
||||
- rotation: Display rotation in degrees counter clockwise (0,90,180,270)
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
PDA 91-00156-A0 5.0" WVGA TFT LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "pda,91-00156-a0"
|
||||
- power-supply: this panel requires a single power supply. A phandle to a
|
||||
regulator needs to be specified here. Compatible with panel-common binding which
|
||||
is specified in the panel-common.txt in this directory.
|
||||
- backlight: this panel's backlight is controlled by an external backlight
|
||||
controller. A phandle to this controller needs to be specified here.
|
||||
Compatible with panel-common binding which is specified in the panel-common.txt
|
||||
in this directory.
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/pda,91-00156-a0.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: PDA 91-00156-A0 5.0" WVGA TFT LCD panel
|
||||
|
||||
maintainers:
|
||||
- Cristian Birsan <cristian.birsan@microchip.com>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: pda,91-00156-a0
|
||||
|
||||
power-supply: true
|
||||
backlight: true
|
||||
port: true
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- power-supply
|
||||
- backlight
|
||||
|
||||
...
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
This binding covers the official 7" (800x480) Raspberry Pi touchscreen
|
||||
panel.
|
||||
|
||||
This DSI panel contains:
|
||||
|
||||
- TC358762 DSI->DPI bridge
|
||||
- Atmel microcontroller on I2C for power sequencing the DSI bridge and
|
||||
controlling backlight
|
||||
- Touchscreen controller on I2C for touch input
|
||||
|
||||
and this binding covers the DSI display parts but not its touch input.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "raspberrypi,7inch-touchscreen-panel"
|
||||
- reg: Must be "45"
|
||||
- port: See panel-common.txt
|
||||
|
||||
Example:
|
||||
|
||||
dsi1: dsi@7e700000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
<...>
|
||||
|
||||
port {
|
||||
dsi_out_port: endpoint {
|
||||
remote-endpoint = <&panel_dsi_port>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
i2c_dsi: i2c {
|
||||
compatible = "i2c-gpio";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
gpios = <&gpio 28 0
|
||||
&gpio 29 0>;
|
||||
|
||||
lcd@45 {
|
||||
compatible = "raspberrypi,7inch-touchscreen-panel";
|
||||
reg = <0x45>;
|
||||
|
||||
port {
|
||||
panel_dsi_port: endpoint {
|
||||
remote-endpoint = <&dsi_out_port>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/raspberrypi,7inch-touchscreen.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: The official 7" (800x480) Raspberry Pi touchscreen
|
||||
|
||||
maintainers:
|
||||
- Eric Anholt <eric@anholt.net>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
description: |+
|
||||
This DSI panel contains:
|
||||
|
||||
- TC358762 DSI->DPI bridge
|
||||
- Atmel microcontroller on I2C for power sequencing the DSI bridge and
|
||||
controlling backlight
|
||||
- Touchscreen controller on I2C for touch input
|
||||
|
||||
and this binding covers the DSI display parts but not its touch input.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: raspberrypi,7inch-touchscreen-panel
|
||||
|
||||
reg:
|
||||
const: 0x45
|
||||
|
||||
port: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- port
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |+
|
||||
dsi1: dsi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port {
|
||||
dsi_out_port: endpoint {
|
||||
remote-endpoint = <&panel_dsi_port>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
i2c_dsi: i2c {
|
||||
compatible = "i2c-gpio";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
scl-gpios = <&gpio 28 0>;
|
||||
sda-gpios = <&gpio 29 0>;
|
||||
|
||||
lcd@45 {
|
||||
compatible = "raspberrypi,7inch-touchscreen-panel";
|
||||
reg = <0x45>;
|
||||
|
||||
port {
|
||||
panel_dsi_port: endpoint {
|
||||
remote-endpoint = <&dsi_out_port>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Raydium RM67171 OLED LCD panel with MIPI-DSI protocol
|
||||
|
||||
Required properties:
|
||||
- compatible: "raydium,rm67191"
|
||||
- reg: virtual channel for MIPI-DSI protocol
|
||||
must be <0>
|
||||
- dsi-lanes: number of DSI lanes to be used
|
||||
must be <3> or <4>
|
||||
- port: input port node with endpoint definition as
|
||||
defined in Documentation/devicetree/bindings/graph.txt;
|
||||
the input port should be connected to a MIPI-DSI device
|
||||
driver
|
||||
|
||||
Optional properties:
|
||||
- reset-gpios: a GPIO spec for the RST_B GPIO pin
|
||||
- v3p3-supply: phandle to 3.3V regulator that powers the VDD_3V3 pin
|
||||
- v1p8-supply: phandle to 1.8V regulator that powers the VDD_1V8 pin
|
||||
- width-mm: see panel-common.txt
|
||||
- height-mm: see panel-common.txt
|
||||
- video-mode: 0 - burst-mode
|
||||
1 - non-burst with sync event
|
||||
2 - non-burst with sync pulse
|
||||
|
||||
Example:
|
||||
|
||||
panel@0 {
|
||||
compatible = "raydium,rm67191";
|
||||
reg = <0>;
|
||||
pinctrl-0 = <&pinctrl_mipi_dsi_0_1_en>;
|
||||
pinctrl-names = "default";
|
||||
reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
|
||||
dsi-lanes = <4>;
|
||||
width-mm = <68>;
|
||||
height-mm = <121>;
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&mipi_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -5,6 +5,9 @@ Required properties:
|
|||
- reg: DSI virtual channel of the peripheral
|
||||
- reset-gpios: panel reset gpio
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
- vcc-supply: phandle of the regulator that provides the vcc supply voltage.
|
||||
- iovcc-supply: phandle of the regulator that provides the iovcc supply
|
||||
voltage.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -14,5 +17,7 @@ Example:
|
|||
reg = <0>;
|
||||
backlight = <&backlight>;
|
||||
reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
|
||||
vcc-supply = <®_2v8_p>;
|
||||
iovcc-supply = <®_1v8_p>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,41 +0,0 @@
|
|||
Solomon Goldentek Display GKTW70SDAE4SE LVDS Display Panel
|
||||
==========================================================
|
||||
|
||||
The GKTW70SDAE4SE is a 7" WVGA TFT-LCD display panel.
|
||||
|
||||
These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
|
||||
with the following device-specific properties.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Shall contain "sgd,gktw70sdae4se" and "panel-lvds", in that order.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
panel {
|
||||
compatible = "sgd,gktw70sdae4se", "panel-lvds";
|
||||
|
||||
width-mm = <153>;
|
||||
height-mm = <86>;
|
||||
|
||||
data-mapping = "jeida-18";
|
||||
|
||||
panel-timing {
|
||||
clock-frequency = <32000000>;
|
||||
hactive = <800>;
|
||||
vactive = <480>;
|
||||
hback-porch = <39>;
|
||||
hfront-porch = <39>;
|
||||
vback-porch = <29>;
|
||||
vfront-porch = <13>;
|
||||
hsync-len = <47>;
|
||||
vsync-len = <2>;
|
||||
};
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&lvds_encoder>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/sgd,gktw70sdae4se.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Solomon Goldentek Display GKTW70SDAE4SE 7" WVGA LVDS Display Panel
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: lvds.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: sgd,gktw70sdae4se
|
||||
- {} # panel-lvds, but not listed here to avoid false select
|
||||
|
||||
data-mapping:
|
||||
const: jeida-18
|
||||
|
||||
width-mm:
|
||||
const: 153
|
||||
|
||||
height-mm:
|
||||
const: 86
|
||||
|
||||
panel-timing: true
|
||||
port: true
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
examples:
|
||||
- |+
|
||||
panel {
|
||||
compatible = "sgd,gktw70sdae4se", "panel-lvds";
|
||||
|
||||
width-mm = <153>;
|
||||
height-mm = <86>;
|
||||
|
||||
data-mapping = "jeida-18";
|
||||
|
||||
panel-timing {
|
||||
clock-frequency = <32000000>;
|
||||
hactive = <800>;
|
||||
vactive = <480>;
|
||||
hback-porch = <39>;
|
||||
hfront-porch = <39>;
|
||||
vback-porch = <29>;
|
||||
vfront-porch = <13>;
|
||||
hsync-len = <47>;
|
||||
vsync-len = <2>;
|
||||
};
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&lvds_encoder>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
Sharp LD-D5116Z01B 12.3" WUXGA+ eDP panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "sharp,ld-d5116z01b"
|
||||
- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
|
||||
|
||||
This binding is compatible with the simple-panel binding.
|
||||
|
||||
The device node can contain one 'port' child node with one child
|
||||
'endpoint' node, according to the bindings defined in [1]. This
|
||||
node should describe panel's video bus.
|
||||
|
||||
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||
|
||||
Example:
|
||||
|
||||
panel: panel {
|
||||
compatible = "sharp,ld-d5116z01b";
|
||||
power-supply = <&vlcd_3v3>;
|
||||
|
||||
port {
|
||||
panel_ep: endpoint {
|
||||
remote-endpoint = <&bridge_out_ep>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
Sharp LQ070Y3DG3B 7.0" WVGA landscape TFT LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "sharp,lq070y3dg3b"
|
||||
|
||||
Optional properties:
|
||||
- enable-gpios: GPIO pin to enable or disable the panel
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
- power-supply: phandle of the regulator that provides the supply voltage
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
Sharp 2.0" (240x160 pixels) 16-bit TFT LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "sharp,ls020b1dd01d"
|
||||
- power-supply: as specified in the base binding
|
||||
|
||||
Optional properties:
|
||||
- backlight: as specified in the base binding
|
||||
- enable-gpios: as specified in the base binding
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
|
@ -1,28 +1 @@
|
|||
Simple display panel
|
||||
====================
|
||||
|
||||
panel node
|
||||
----------
|
||||
|
||||
Required properties:
|
||||
- power-supply: See panel-common.txt
|
||||
|
||||
Optional properties:
|
||||
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
|
||||
- enable-gpios: GPIO pin to enable or disable the panel
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
- no-hpd: This panel is supposed to communicate that it's ready via HPD
|
||||
(hot plug detect) signal, but the signal isn't hooked up so we should
|
||||
hardcode the max delay from the panel spec when powering up the panel.
|
||||
|
||||
Example:
|
||||
|
||||
panel: panel {
|
||||
compatible = "cptt,claa101wb01";
|
||||
ddc-i2c-bus = <&panelddc>;
|
||||
|
||||
power-supply = <&vdd_pnl_reg>;
|
||||
enable-gpios = <&gpio 90 0>;
|
||||
|
||||
backlight = <&backlight>;
|
||||
};
|
||||
See panel-common.yaml in this directory.
|
||||
|
|
|
|||
|
|
@ -1,15 +0,0 @@
|
|||
TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with
|
||||
resistive touch
|
||||
|
||||
The panel is found on TI AM335x-evm.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "tfc,s9700rtwv43tr-01b"
|
||||
- power-supply: See panel-common.txt
|
||||
|
||||
Optional properties:
|
||||
- enable-gpios: GPIO pin to enable or disable the panel, if there is one
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/tfc,s9700rtwv43tr-01b.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with resistive touch
|
||||
|
||||
maintainers:
|
||||
- Jyri Sarha <jsarha@ti.com>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
description: |+
|
||||
The panel is found on TI AM335x-evm.
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: tfc,s9700rtwv43tr-01b
|
||||
|
||||
enable-gpios: true
|
||||
backlight: true
|
||||
port: true
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- power-supply
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/ti,nspire.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Texas Instruments NSPIRE Display Panels
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ti,nspire-cx-lcd-panel
|
||||
- ti,nspire-classic-lcd-panel
|
||||
port: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
panel {
|
||||
compatible = "ti,nspire-cx-lcd-panel";
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&pads>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
TPO TPG110 Panel
|
||||
================
|
||||
|
||||
This panel driver is a component that acts as an intermediary
|
||||
between an RGB output and a variety of panels. The panel
|
||||
driver is strapped up in electronics to the desired resolution
|
||||
and other properties, and has a control interface over 3WIRE
|
||||
SPI. By talking to the TPG110 over SPI, the strapped properties
|
||||
can be discovered and the hardware is therefore mostly
|
||||
self-describing.
|
||||
|
||||
+--------+
|
||||
SPI -> | TPO | -> physical display
|
||||
RGB -> | TPG110 |
|
||||
+--------+
|
||||
|
||||
If some electrical strap or alternate resolution is desired,
|
||||
this can be set up by taking software control of the display
|
||||
over the SPI interface. The interface can also adjust
|
||||
for properties of the display such as gamma correction and
|
||||
certain electrical driving levels.
|
||||
|
||||
The TPG110 does not know the physical dimensions of the panel
|
||||
connected, so this needs to be specified in the device tree.
|
||||
|
||||
It requires a GPIO line for control of its reset line.
|
||||
|
||||
The serial protocol has line names that resemble I2C but the
|
||||
protocol is not I2C but 3WIRE SPI.
|
||||
|
||||
Required properties:
|
||||
- compatible : one of:
|
||||
"ste,nomadik-nhk15-display", "tpo,tpg110"
|
||||
"tpo,tpg110"
|
||||
- grestb-gpios : panel reset GPIO
|
||||
- width-mm : see display/panel/panel-common.txt
|
||||
- height-mm : see display/panel/panel-common.txt
|
||||
|
||||
The device needs to be a child of an SPI bus, see
|
||||
spi/spi-bus.txt. The SPI child must set the following
|
||||
properties:
|
||||
- spi-3wire
|
||||
- spi-max-frequency = <3000000>;
|
||||
as these are characteristics of this device.
|
||||
|
||||
The device node can contain one 'port' child node with one child
|
||||
'endpoint' node, according to the bindings defined in
|
||||
media/video-interfaces.txt. This node should describe panel's video bus.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
panel: display@0 {
|
||||
compatible = "tpo,tpg110";
|
||||
reg = <0>;
|
||||
spi-3wire;
|
||||
/* 320 ns min period ~= 3 MHz */
|
||||
spi-max-frequency = <3000000>;
|
||||
/* Width and height from data sheet */
|
||||
width-mm = <116>;
|
||||
height-mm = <87>;
|
||||
grestb-gpios = <&foo_gpio 5 GPIO_ACTIVE_LOW>;
|
||||
backlight = <&bl>;
|
||||
|
||||
port {
|
||||
nomadik_clcd_panel: endpoint {
|
||||
remote-endpoint = <&foo>;
|
||||
};
|
||||
};
|
||||
};
|
||||
101
Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
Normal file
101
Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
Normal file
|
|
@ -0,0 +1,101 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/tpo,tpg110.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TPO TPG110 Panel
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
description: |+
|
||||
This panel driver is a component that acts as an intermediary
|
||||
between an RGB output and a variety of panels. The panel
|
||||
driver is strapped up in electronics to the desired resolution
|
||||
and other properties, and has a control interface over 3WIRE
|
||||
SPI. By talking to the TPG110 over SPI, the strapped properties
|
||||
can be discovered and the hardware is therefore mostly
|
||||
self-describing.
|
||||
|
||||
+--------+
|
||||
SPI -> | TPO | -> physical display
|
||||
RGB -> | TPG110 |
|
||||
+--------+
|
||||
|
||||
If some electrical strap or alternate resolution is desired,
|
||||
this can be set up by taking software control of the display
|
||||
over the SPI interface. The interface can also adjust
|
||||
for properties of the display such as gamma correction and
|
||||
certain electrical driving levels.
|
||||
|
||||
The TPG110 does not know the physical dimensions of the panel
|
||||
connected, so this needs to be specified in the device tree.
|
||||
|
||||
It requires a GPIO line for control of its reset line.
|
||||
|
||||
The serial protocol has line names that resemble I2C but the
|
||||
protocol is not I2C but 3WIRE SPI.
|
||||
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- ste,nomadik-nhk15-display
|
||||
- const: tpo,tpg110
|
||||
- const: tpo,tpg110
|
||||
|
||||
reg: true
|
||||
|
||||
grestb-gpios:
|
||||
maxItems: 1
|
||||
description: panel reset GPIO
|
||||
|
||||
spi-3wire: true
|
||||
|
||||
spi-max-frequency:
|
||||
const: 3000000
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- grestb-gpios
|
||||
- width-mm
|
||||
- height-mm
|
||||
- spi-3wire
|
||||
- spi-max-frequency
|
||||
- port
|
||||
|
||||
examples:
|
||||
- |+
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
panel: display@0 {
|
||||
compatible = "tpo,tpg110";
|
||||
reg = <0>;
|
||||
spi-3wire;
|
||||
/* 320 ns min period ~= 3 MHz */
|
||||
spi-max-frequency = <3000000>;
|
||||
/* Width and height from data sheet */
|
||||
width-mm = <116>;
|
||||
height-mm = <87>;
|
||||
grestb-gpios = <&foo_gpio 5 1>;
|
||||
backlight = <&bl>;
|
||||
|
||||
port {
|
||||
nomadik_clcd_panel: endpoint {
|
||||
remote-endpoint = <&foo>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -14,6 +14,8 @@ Required properties:
|
|||
- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
|
||||
- ports: contain a port node with endpoint definitions as defined in [2].
|
||||
For vopb,set the reg = <0> and set the reg = <1> for vopl.
|
||||
- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
|
||||
- video port 1 for either a panel or subsequent encoder
|
||||
|
||||
Optional properties:
|
||||
- power-domains: a phandle to mipi dsi power domain node.
|
||||
|
|
@ -40,11 +42,12 @@ Example:
|
|||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <1>;
|
||||
|
||||
mipi_in: port {
|
||||
mipi_in: port@0 {
|
||||
reg = <0>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
mipi_in_vopb: endpoint@0 {
|
||||
reg = <0>;
|
||||
remote-endpoint = <&vopb_out_mipi>;
|
||||
|
|
@ -54,6 +57,16 @@ Example:
|
|||
remote-endpoint = <&vopl_out_mipi>;
|
||||
};
|
||||
};
|
||||
|
||||
mipi_out: port@1 {
|
||||
reg = <1>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
mipi_out_panel: endpoint {
|
||||
remote-endpoint = <&panel_in_mipi>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
panel {
|
||||
|
|
@ -64,5 +77,11 @@ Example:
|
|||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&lcd_en>;
|
||||
backlight = <&backlight>;
|
||||
|
||||
port {
|
||||
panel_in_mipi: endpoint {
|
||||
remote-endpoint = <&mipi_out_panel>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -32,17 +32,6 @@ Their connections are modeled using the OF graph bindings specified in
|
|||
- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
|
||||
- video port 1 for either a panel or subsequent encoder
|
||||
|
||||
the lvds panel described by
|
||||
Documentation/devicetree/bindings/display/panel/simple-panel.txt
|
||||
|
||||
Panel required properties:
|
||||
- ports for remote LVDS output
|
||||
|
||||
Panel optional properties:
|
||||
- data-mapping: should be "vesa-24","jeida-24" or "jeida-18".
|
||||
This describes decribed by:
|
||||
Documentation/devicetree/bindings/display/panel/panel-lvds.txt
|
||||
|
||||
Example:
|
||||
|
||||
lvds_panel: lvds-panel {
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user