Merge 'master' into 'os-build'
This commit is contained in:
Fedora Kernel Team
commit
ba6c7d299d
1
.mailmap
1
.mailmap
|
|
@ -100,6 +100,7 @@ Douglas Gilbert <dougg@torque.net>
|
|||
Ed L. Cashin <ecashin@coraid.com>
|
||||
Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>
|
||||
Evgeniy Polyakov <johnpol@2ka.mipt.ru>
|
||||
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com>
|
||||
Felipe W Damasio <felipewd@terra.com.br>
|
||||
Felix Kuhling <fxkuehl@gmx.de>
|
||||
Felix Moeller <felix@derklecks.de>
|
||||
|
|
|
|||
|
|
@ -42,6 +42,12 @@ Description: the CPU core ID of cpuX. Typically it is the hardware platform's
|
|||
architecture and platform dependent.
|
||||
Values: integer
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/cluster_id
|
||||
Description: the cluster ID of cpuX. Typically it is the hardware platform's
|
||||
identifier (rather than the kernel's). The actual value is
|
||||
architecture and platform dependent.
|
||||
Values: integer
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/book_id
|
||||
Description: the book ID of cpuX. Typically it is the hardware platform's
|
||||
identifier (rather than the kernel's). The actual value is
|
||||
|
|
@ -85,6 +91,15 @@ Description: human-readable list of CPUs within the same die.
|
|||
The format is like 0-3, 8-11, 14,17.
|
||||
Values: decimal list.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/cluster_cpus
|
||||
Description: internal kernel map of CPUs within the same cluster.
|
||||
Values: hexadecimal bitmask.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/cluster_cpus_list
|
||||
Description: human-readable list of CPUs within the same cluster.
|
||||
The format is like 0-3, 8-11, 14,17.
|
||||
Values: decimal list.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/book_siblings
|
||||
Description: internal kernel map of cpuX's hardware threads within the same
|
||||
book_id. it's only used on s390.
|
||||
|
|
|
|||
|
|
@ -202,49 +202,44 @@ newly arrived RCU callbacks against future grace periods:
|
|||
1 static void rcu_prepare_for_idle(void)
|
||||
2 {
|
||||
3 bool needwake;
|
||||
4 struct rcu_data *rdp;
|
||||
5 struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
|
||||
6 struct rcu_node *rnp;
|
||||
7 struct rcu_state *rsp;
|
||||
8 int tne;
|
||||
9
|
||||
10 if (IS_ENABLED(CONFIG_RCU_NOCB_CPU_ALL) ||
|
||||
11 rcu_is_nocb_cpu(smp_processor_id()))
|
||||
12 return;
|
||||
4 struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
|
||||
5 struct rcu_node *rnp;
|
||||
6 int tne;
|
||||
7
|
||||
8 lockdep_assert_irqs_disabled();
|
||||
9 if (rcu_rdp_is_offloaded(rdp))
|
||||
10 return;
|
||||
11
|
||||
12 /* Handle nohz enablement switches conservatively. */
|
||||
13 tne = READ_ONCE(tick_nohz_active);
|
||||
14 if (tne != rdtp->tick_nohz_enabled_snap) {
|
||||
15 if (rcu_cpu_has_callbacks(NULL))
|
||||
16 invoke_rcu_core();
|
||||
17 rdtp->tick_nohz_enabled_snap = tne;
|
||||
14 if (tne != rdp->tick_nohz_enabled_snap) {
|
||||
15 if (!rcu_segcblist_empty(&rdp->cblist))
|
||||
16 invoke_rcu_core(); /* force nohz to see update. */
|
||||
17 rdp->tick_nohz_enabled_snap = tne;
|
||||
18 return;
|
||||
19 }
|
||||
19 }
|
||||
20 if (!tne)
|
||||
21 return;
|
||||
22 if (rdtp->all_lazy &&
|
||||
23 rdtp->nonlazy_posted != rdtp->nonlazy_posted_snap) {
|
||||
24 rdtp->all_lazy = false;
|
||||
25 rdtp->nonlazy_posted_snap = rdtp->nonlazy_posted;
|
||||
26 invoke_rcu_core();
|
||||
27 return;
|
||||
28 }
|
||||
29 if (rdtp->last_accelerate == jiffies)
|
||||
30 return;
|
||||
31 rdtp->last_accelerate = jiffies;
|
||||
32 for_each_rcu_flavor(rsp) {
|
||||
33 rdp = this_cpu_ptr(rsp->rda);
|
||||
34 if (rcu_segcblist_pend_cbs(&rdp->cblist))
|
||||
35 continue;
|
||||
36 rnp = rdp->mynode;
|
||||
37 raw_spin_lock_rcu_node(rnp);
|
||||
38 needwake = rcu_accelerate_cbs(rsp, rnp, rdp);
|
||||
39 raw_spin_unlock_rcu_node(rnp);
|
||||
40 if (needwake)
|
||||
41 rcu_gp_kthread_wake(rsp);
|
||||
42 }
|
||||
43 }
|
||||
22
|
||||
23 /*
|
||||
24 * If we have not yet accelerated this jiffy, accelerate all
|
||||
25 * callbacks on this CPU.
|
||||
26 */
|
||||
27 if (rdp->last_accelerate == jiffies)
|
||||
28 return;
|
||||
29 rdp->last_accelerate = jiffies;
|
||||
30 if (rcu_segcblist_pend_cbs(&rdp->cblist)) {
|
||||
31 rnp = rdp->mynode;
|
||||
32 raw_spin_lock_rcu_node(rnp); /* irqs already disabled. */
|
||||
33 needwake = rcu_accelerate_cbs(rnp, rdp);
|
||||
34 raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */
|
||||
35 if (needwake)
|
||||
36 rcu_gp_kthread_wake();
|
||||
37 }
|
||||
38 }
|
||||
|
||||
But the only part of ``rcu_prepare_for_idle()`` that really matters for
|
||||
this discussion are lines 37–39. We will therefore abbreviate this
|
||||
this discussion are lines 32–34. We will therefore abbreviate this
|
||||
function as follows:
|
||||
|
||||
.. kernel-figure:: rcu_node-lock.svg
|
||||
|
|
|
|||
|
|
@ -96,6 +96,16 @@ warnings:
|
|||
the ``rcu_.*timer wakeup didn't happen for`` console-log message,
|
||||
which will include additional debugging information.
|
||||
|
||||
- A low-level kernel issue that either fails to invoke one of the
|
||||
variants of rcu_user_enter(), rcu_user_exit(), rcu_idle_enter(),
|
||||
rcu_idle_exit(), rcu_irq_enter(), or rcu_irq_exit() on the one
|
||||
hand, or that invokes one of them too many times on the other.
|
||||
Historically, the most frequent issue has been an omission
|
||||
of either irq_enter() or irq_exit(), which in turn invoke
|
||||
rcu_irq_enter() or rcu_irq_exit(), respectively. Building your
|
||||
kernel with CONFIG_RCU_EQS_DEBUG=y can help track down these types
|
||||
of issues, which sometimes arise in architecture-specific code.
|
||||
|
||||
- A bug in the RCU implementation.
|
||||
|
||||
- A hardware failure. This is quite unlikely, but has occurred
|
||||
|
|
|
|||
|
|
@ -1016,6 +1016,8 @@ All time durations are in microseconds.
|
|||
- nr_periods
|
||||
- nr_throttled
|
||||
- throttled_usec
|
||||
- nr_bursts
|
||||
- burst_usec
|
||||
|
||||
cpu.weight
|
||||
A read-write single value file which exists on non-root
|
||||
|
|
@ -1047,6 +1049,12 @@ All time durations are in microseconds.
|
|||
$PERIOD duration. "max" for $MAX indicates no limit. If only
|
||||
one number is written, $MAX is updated.
|
||||
|
||||
cpu.max.burst
|
||||
A read-write single value file which exists on non-root
|
||||
cgroups. The default is "0".
|
||||
|
||||
The burst in the range [0, $MAX].
|
||||
|
||||
cpu.pressure
|
||||
A read-write nested-keyed file.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,11 +19,13 @@ these macros in include/asm-XXX/topology.h::
|
|||
|
||||
#define topology_physical_package_id(cpu)
|
||||
#define topology_die_id(cpu)
|
||||
#define topology_cluster_id(cpu)
|
||||
#define topology_core_id(cpu)
|
||||
#define topology_book_id(cpu)
|
||||
#define topology_drawer_id(cpu)
|
||||
#define topology_sibling_cpumask(cpu)
|
||||
#define topology_core_cpumask(cpu)
|
||||
#define topology_cluster_cpumask(cpu)
|
||||
#define topology_die_cpumask(cpu)
|
||||
#define topology_book_cpumask(cpu)
|
||||
#define topology_drawer_cpumask(cpu)
|
||||
|
|
@ -39,10 +41,12 @@ not defined by include/asm-XXX/topology.h:
|
|||
|
||||
1) topology_physical_package_id: -1
|
||||
2) topology_die_id: -1
|
||||
3) topology_core_id: 0
|
||||
4) topology_sibling_cpumask: just the given CPU
|
||||
5) topology_core_cpumask: just the given CPU
|
||||
6) topology_die_cpumask: just the given CPU
|
||||
3) topology_cluster_id: -1
|
||||
4) topology_core_id: 0
|
||||
5) topology_sibling_cpumask: just the given CPU
|
||||
6) topology_core_cpumask: just the given CPU
|
||||
7) topology_cluster_cpumask: just the given CPU
|
||||
8) topology_die_cpumask: just the given CPU
|
||||
|
||||
For architectures that don't support books (CONFIG_SCHED_BOOK) there are no
|
||||
default definitions for topology_book_id() and topology_book_cpumask().
|
||||
|
|
|
|||
|
|
@ -490,9 +490,8 @@ Spectre variant 2
|
|||
|
||||
Restricting indirect branch speculation on a user program will
|
||||
also prevent the program from launching a variant 2 attack
|
||||
on x86. All sand-boxed SECCOMP programs have indirect branch
|
||||
speculation restricted by default. Administrators can change
|
||||
that behavior via the kernel command line and sysfs control files.
|
||||
on x86. Administrators can change that behavior via the kernel
|
||||
command line and sysfs control files.
|
||||
See :ref:`spectre_mitigation_control_command_line`.
|
||||
|
||||
Programs that disable their indirect branch speculation will have
|
||||
|
|
@ -594,61 +593,14 @@ kernel command line.
|
|||
Not specifying this option is equivalent to
|
||||
spectre_v2=auto.
|
||||
|
||||
For user space mitigation:
|
||||
|
||||
spectre_v2_user=
|
||||
|
||||
[X86] Control mitigation of Spectre variant 2
|
||||
(indirect branch speculation) vulnerability between
|
||||
user space tasks
|
||||
|
||||
on
|
||||
Unconditionally enable mitigations. Is
|
||||
enforced by spectre_v2=on
|
||||
|
||||
off
|
||||
Unconditionally disable mitigations. Is
|
||||
enforced by spectre_v2=off
|
||||
|
||||
prctl
|
||||
Indirect branch speculation is enabled,
|
||||
but mitigation can be enabled via prctl
|
||||
per thread. The mitigation control state
|
||||
is inherited on fork.
|
||||
|
||||
prctl,ibpb
|
||||
Like "prctl" above, but only STIBP is
|
||||
controlled per thread. IBPB is issued
|
||||
always when switching between different user
|
||||
space processes.
|
||||
|
||||
seccomp
|
||||
Same as "prctl" above, but all seccomp
|
||||
threads will enable the mitigation unless
|
||||
they explicitly opt out.
|
||||
|
||||
seccomp,ibpb
|
||||
Like "seccomp" above, but only STIBP is
|
||||
controlled per thread. IBPB is issued
|
||||
always when switching between different
|
||||
user space processes.
|
||||
|
||||
auto
|
||||
Kernel selects the mitigation depending on
|
||||
the available CPU features and vulnerability.
|
||||
|
||||
Default mitigation:
|
||||
If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"
|
||||
|
||||
Not specifying this option is equivalent to
|
||||
spectre_v2_user=auto.
|
||||
|
||||
In general the kernel by default selects
|
||||
reasonable mitigations for the current CPU. To
|
||||
disable Spectre variant 2 mitigations, boot with
|
||||
spectre_v2=off. Spectre variant 1 mitigations
|
||||
cannot be disabled.
|
||||
|
||||
For spectre_v2_user see :doc:`/admin-guide/kernel-parameters`.
|
||||
|
||||
Mitigation selection guide
|
||||
--------------------------
|
||||
|
||||
|
|
@ -674,9 +626,8 @@ Mitigation selection guide
|
|||
off by disabling their indirect branch speculation when they are run
|
||||
(See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
|
||||
This prevents untrusted programs from polluting the branch target
|
||||
buffer. All programs running in SECCOMP sandboxes have indirect
|
||||
branch speculation restricted by default. This behavior can be
|
||||
changed via the kernel command line and sysfs control files. See
|
||||
buffer. This behavior can be changed via the kernel command line
|
||||
and sysfs control files. See
|
||||
:ref:`spectre_mitigation_control_command_line`.
|
||||
|
||||
3. High security mode
|
||||
|
|
|
|||
|
|
@ -5303,8 +5303,7 @@
|
|||
auto - Kernel selects the mitigation depending on
|
||||
the available CPU features and vulnerability.
|
||||
|
||||
Default mitigation:
|
||||
If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"
|
||||
Default mitigation: "prctl"
|
||||
|
||||
Not specifying this option is equivalent to
|
||||
spectre_v2_user=auto.
|
||||
|
|
@ -5348,7 +5347,7 @@
|
|||
will disable SSB unless they explicitly opt out.
|
||||
|
||||
Default mitigations:
|
||||
X86: If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
|
||||
X86: "prctl"
|
||||
|
||||
On powerpc the options are:
|
||||
|
||||
|
|
@ -5497,6 +5496,15 @@
|
|||
stifb= [HW]
|
||||
Format: bpp:<bpp1>[:<bpp2>[:<bpp3>...]]
|
||||
|
||||
strict_sas_size=
|
||||
[X86]
|
||||
Format: <bool>
|
||||
Enable or disable strict sigaltstack size checks
|
||||
against the required signal frame size which
|
||||
depends on the supported FPU features. This can
|
||||
be used to filter out binaries which have
|
||||
not yet been made aware of AT_MINSIGSTKSZ.
|
||||
|
||||
sunrpc.min_resvport=
|
||||
sunrpc.max_resvport=
|
||||
[NFS,SUNRPC]
|
||||
|
|
|
|||
|
|
@ -58,15 +58,20 @@ Camera sensor devices
|
|||
============ ==========================================================
|
||||
Driver Name
|
||||
============ ==========================================================
|
||||
ccs MIPI CCS compliant camera sensors (also SMIA++ and SMIA)
|
||||
et8ek8 ET8EK8 camera sensor
|
||||
hi556 Hynix Hi-556 sensor
|
||||
hi846 Hynix Hi-846 sensor
|
||||
imx208 Sony IMX208 sensor
|
||||
imx214 Sony IMX214 sensor
|
||||
imx219 Sony IMX219 sensor
|
||||
imx258 Sony IMX258 sensor
|
||||
imx274 Sony IMX274 sensor
|
||||
imx290 Sony IMX290 sensor
|
||||
imx319 Sony IMX319 sensor
|
||||
imx334 Sony IMX334 sensor
|
||||
imx355 Sony IMX355 sensor
|
||||
imx412 Sony IMX412 sensor
|
||||
m5mols Fujitsu M-5MOLS 8MP sensor
|
||||
mt9m001 mt9m001
|
||||
mt9m032 MT9M032 camera sensor
|
||||
|
|
@ -79,6 +84,7 @@ mt9v032 Micron MT9V032 sensor
|
|||
mt9v111 Aptina MT9V111 sensor
|
||||
noon010pc30 Siliconfile NOON010PC30 sensor
|
||||
ov13858 OmniVision OV13858 sensor
|
||||
ov13b10 OmniVision OV13B10 sensor
|
||||
ov2640 OmniVision OV2640 sensor
|
||||
ov2659 OmniVision OV2659 sensor
|
||||
ov2680 OmniVision OV2680 sensor
|
||||
|
|
@ -104,7 +110,6 @@ s5k4ecgx Samsung S5K4ECGX sensor
|
|||
s5k5baf Samsung S5K5BAF sensor
|
||||
s5k6a3 Samsung S5K6A3 sensor
|
||||
s5k6aa Samsung S5K6AAFX sensor
|
||||
smiapp SMIA++/SMIA sensor
|
||||
sr030pc30 Siliconfile SR030PC30 sensor
|
||||
vs6624 ST VS6624 sensor
|
||||
============ ==========================================================
|
||||
|
|
@ -138,6 +143,7 @@ Driver Name
|
|||
ad5820 AD5820 lens voice coil
|
||||
ak7375 AK7375 lens voice coil
|
||||
dw9714 DW9714 lens voice coil
|
||||
dw9768 DW9768 lens voice coil
|
||||
dw9807-vcm DW9807 lens voice coil
|
||||
============ ==========================================================
|
||||
|
||||
|
|
|
|||
|
|
@ -155,6 +155,66 @@ the resolutions supported by the sensor.
|
|||
[fmt:SBGGR10_1X10/800x600@1/30 field:none colorspace:srgb]
|
||||
-> "imx7-mipi-csis.0":0 [ENABLED]
|
||||
|
||||
i.MX6ULL-EVK with OV5640
|
||||
------------------------
|
||||
|
||||
On this platform a parallel OV5640 sensor is connected to the CSI port.
|
||||
The following example configures a video capture pipeline with an output
|
||||
of 640x480 and UYVY8_2X8 format:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
# Setup links
|
||||
media-ctl -l "'ov5640 1-003c':0 -> 'csi':0[1]"
|
||||
media-ctl -l "'csi':1 -> 'csi capture':0[1]"
|
||||
|
||||
# Configure pads for pipeline
|
||||
media-ctl -v -V "'ov5640 1-003c':0 [fmt:UYVY8_2X8/640x480 field:none]"
|
||||
|
||||
After this streaming can start:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
gst-launch-1.0 -v v4l2src device=/dev/video1 ! video/x-raw,format=UYVY,width=640,height=480 ! v4l2convert ! fbdevsink
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
# media-ctl -p
|
||||
Media controller API version 5.14.0
|
||||
|
||||
Media device information
|
||||
------------------------
|
||||
driver imx7-csi
|
||||
model imx-media
|
||||
serial
|
||||
bus info
|
||||
hw revision 0x0
|
||||
driver version 5.14.0
|
||||
|
||||
Device topology
|
||||
- entity 1: csi (2 pads, 2 links)
|
||||
type V4L2 subdev subtype Unknown flags 0
|
||||
device node name /dev/v4l-subdev0
|
||||
pad0: Sink
|
||||
[fmt:UYVY8_2X8/640x480 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range]
|
||||
<- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]
|
||||
pad1: Source
|
||||
[fmt:UYVY8_2X8/640x480 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range]
|
||||
-> "csi capture":0 [ENABLED,IMMUTABLE]
|
||||
|
||||
- entity 4: csi capture (1 pad, 1 link)
|
||||
type Node subtype V4L flags 0
|
||||
device node name /dev/video1
|
||||
pad0: Sink
|
||||
<- "csi":1 [ENABLED,IMMUTABLE]
|
||||
|
||||
- entity 10: ov5640 1-003c (1 pad, 1 link)
|
||||
type V4L2 subdev subtype Sensor flags 0
|
||||
device node name /dev/v4l-subdev1
|
||||
pad0: Source
|
||||
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range]
|
||||
-> "csi":0 [ENABLED,IMMUTABLE]
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
|
|
|
|||
|
|
@ -51,10 +51,11 @@ to userspace as a V4L2 sub-device node and has two pads:
|
|||
.. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}|
|
||||
|
||||
.. flat-table::
|
||||
:header-rows: 1
|
||||
|
||||
* - pad
|
||||
- direction
|
||||
- purpose
|
||||
* - Pad
|
||||
- Direction
|
||||
- Purpose
|
||||
|
||||
* - 0
|
||||
- sink
|
||||
|
|
@ -148,10 +149,11 @@ Each pipe has two sink pads and three source pads for the following purpose:
|
|||
.. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}|
|
||||
|
||||
.. flat-table::
|
||||
:header-rows: 1
|
||||
|
||||
* - pad
|
||||
- direction
|
||||
- purpose
|
||||
* - Pad
|
||||
- Direction
|
||||
- Purpose
|
||||
|
||||
* - 0
|
||||
- sink
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ whatever). Otherwise the device numbers can get confusing. The ivtv
|
|||
Read-only
|
||||
|
||||
The raw YUV video output from the current video input. The YUV format
|
||||
is non-standard (V4L2_PIX_FMT_HM12).
|
||||
is a 16x16 linear tiled NV12 format (V4L2_PIX_FMT_NV12_16L16)
|
||||
|
||||
Note that the YUV and PCM streams are not synchronized, so they are of
|
||||
limited use.
|
||||
|
|
|
|||
|
|
@ -61,9 +61,10 @@ vimc-debayer:
|
|||
* 1 Pad source
|
||||
|
||||
vimc-scaler:
|
||||
Scale up the image by a factor of 3. E.g.: a 640x480 image becomes a
|
||||
1920x1440 image. (this value can be configured, see at
|
||||
`Module options`_).
|
||||
Re-size the image to meet the source pad resolution. E.g.: if the sync
|
||||
pad is configured to 360x480 and the source to 1280x720, the image will
|
||||
be stretched to fit the source resolution. Works for any resolution
|
||||
within the vimc limitations (even shrinking the image if necessary).
|
||||
Exposes:
|
||||
|
||||
* 1 Pad sink
|
||||
|
|
@ -75,16 +76,3 @@ vimc-capture:
|
|||
|
||||
* 1 Pad sink
|
||||
* 1 Pad source
|
||||
|
||||
|
||||
Module options
|
||||
--------------
|
||||
|
||||
Vimc has a module parameter to configure the driver.
|
||||
|
||||
* ``sca_mult=<unsigned int>``
|
||||
|
||||
Image size multiplier factor to be used to multiply both width and
|
||||
height, so the image size will be ``sca_mult^2`` bigger than the
|
||||
original one. Currently, only supports scaling up (the default value
|
||||
is 3).
|
||||
|
|
|
|||
|
|
@ -340,6 +340,16 @@ Before jumping into the kernel, the following conditions must be met:
|
|||
- SMCR_EL2.LEN must be initialised to the same value for all CPUs the
|
||||
kernel will execute on.
|
||||
|
||||
For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64)
|
||||
|
||||
- If EL3 is present:
|
||||
|
||||
- SMCR_EL3.FA64 (bit 31) must be initialised to 0b1.
|
||||
|
||||
- If the kernel is entered at EL1 and EL2 is present:
|
||||
|
||||
- SMCR_EL2.FA64 (bit 31) must be initialised to 0b1.
|
||||
|
||||
The requirements described above for CPU mode, caches, MMUs, architected
|
||||
timers, coherency and system registers apply to all CPUs. All CPUs must
|
||||
enter the kernel in the same exception level. Where the values documented
|
||||
|
|
|
|||
|
|
@ -235,7 +235,15 @@ infrastructure:
|
|||
| DPB | [3-0] | y |
|
||||
+------------------------------+---------+---------+
|
||||
|
||||
6) ID_AA64MMFR2_EL1 - Memory model feature register 2
|
||||
6) ID_AA64MMFR0_EL1 - Memory model feature register 0
|
||||
|
||||
+------------------------------+---------+---------+
|
||||
| Name | bits | visible |
|
||||
+------------------------------+---------+---------+
|
||||
| ECV | [63-60] | y |
|
||||
+------------------------------+---------+---------+
|
||||
|
||||
7) ID_AA64MMFR2_EL1 - Memory model feature register 2
|
||||
|
||||
+------------------------------+---------+---------+
|
||||
| Name | bits | visible |
|
||||
|
|
@ -243,7 +251,7 @@ infrastructure:
|
|||
| AT | [35-32] | y |
|
||||
+------------------------------+---------+---------+
|
||||
|
||||
7) ID_AA64ZFR0_EL1 - SVE feature ID register 0
|
||||
8) ID_AA64ZFR0_EL1 - SVE feature ID register 0
|
||||
|
||||
+------------------------------+---------+---------+
|
||||
| Name | bits | visible |
|
||||
|
|
|
|||
|
|
@ -247,6 +247,10 @@ HWCAP2_MTE
|
|||
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
|
||||
by Documentation/arm64/memory-tagging-extension.rst.
|
||||
|
||||
HWCAP2_ECV
|
||||
|
||||
Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
|
||||
|
||||
4. Unused AT_HWCAP bits
|
||||
-----------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -92,12 +92,24 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #1349291 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | MMU-500 | #841119,826419 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. _inline_encryption:
|
||||
|
||||
=================
|
||||
Inline Encryption
|
||||
=================
|
||||
|
|
@ -7,230 +9,269 @@ Inline Encryption
|
|||
Background
|
||||
==========
|
||||
|
||||
Inline encryption hardware sits logically between memory and the disk, and can
|
||||
en/decrypt data as it goes in/out of the disk. Inline encryption hardware has a
|
||||
fixed number of "keyslots" - slots into which encryption contexts (i.e. the
|
||||
encryption key, encryption algorithm, data unit size) can be programmed by the
|
||||
kernel at any time. Each request sent to the disk can be tagged with the index
|
||||
of a keyslot (and also a data unit number to act as an encryption tweak), and
|
||||
the inline encryption hardware will en/decrypt the data in the request with the
|
||||
encryption context programmed into that keyslot. This is very different from
|
||||
full disk encryption solutions like self encrypting drives/TCG OPAL/ATA
|
||||
Security standards, since with inline encryption, any block on disk could be
|
||||
encrypted with any encryption context the kernel chooses.
|
||||
Inline encryption hardware sits logically between memory and disk, and can
|
||||
en/decrypt data as it goes in/out of the disk. For each I/O request, software
|
||||
can control exactly how the inline encryption hardware will en/decrypt the data
|
||||
in terms of key, algorithm, data unit size (the granularity of en/decryption),
|
||||
and data unit number (a value that determines the initialization vector(s)).
|
||||
|
||||
Some inline encryption hardware accepts all encryption parameters including raw
|
||||
keys directly in low-level I/O requests. However, most inline encryption
|
||||
hardware instead has a fixed number of "keyslots" and requires that the key,
|
||||
algorithm, and data unit size first be programmed into a keyslot. Each
|
||||
low-level I/O request then just contains a keyslot index and data unit number.
|
||||
|
||||
Note that inline encryption hardware is very different from traditional crypto
|
||||
accelerators, which are supported through the kernel crypto API. Traditional
|
||||
crypto accelerators operate on memory regions, whereas inline encryption
|
||||
hardware operates on I/O requests. Thus, inline encryption hardware needs to be
|
||||
managed by the block layer, not the kernel crypto API.
|
||||
|
||||
Inline encryption hardware is also very different from "self-encrypting drives",
|
||||
such as those based on the TCG Opal or ATA Security standards. Self-encrypting
|
||||
drives don't provide fine-grained control of encryption and provide no way to
|
||||
verify the correctness of the resulting ciphertext. Inline encryption hardware
|
||||
provides fine-grained control of encryption, including the choice of key and
|
||||
initialization vector for each sector, and can be tested for correctness.
|
||||
|
||||
Objective
|
||||
=========
|
||||
|
||||
We want to support inline encryption (IE) in the kernel.
|
||||
To allow for testing, we also want a crypto API fallback when actual
|
||||
IE hardware is absent. We also want IE to work with layered devices
|
||||
like dm and loopback (i.e. we want to be able to use the IE hardware
|
||||
of the underlying devices if present, or else fall back to crypto API
|
||||
en/decryption).
|
||||
|
||||
We want to support inline encryption in the kernel. To make testing easier, we
|
||||
also want support for falling back to the kernel crypto API when actual inline
|
||||
encryption hardware is absent. We also want inline encryption to work with
|
||||
layered devices like device-mapper and loopback (i.e. we want to be able to use
|
||||
the inline encryption hardware of the underlying devices if present, or else
|
||||
fall back to crypto API en/decryption).
|
||||
|
||||
Constraints and notes
|
||||
=====================
|
||||
|
||||
- IE hardware has a limited number of "keyslots" that can be programmed
|
||||
with an encryption context (key, algorithm, data unit size, etc.) at any time.
|
||||
One can specify a keyslot in a data request made to the device, and the
|
||||
device will en/decrypt the data using the encryption context programmed into
|
||||
that specified keyslot. When possible, we want to make multiple requests with
|
||||
the same encryption context share the same keyslot.
|
||||
- We need a way for upper layers (e.g. filesystems) to specify an encryption
|
||||
context to use for en/decrypting a bio, and device drivers (e.g. UFSHCD) need
|
||||
to be able to use that encryption context when they process the request.
|
||||
Encryption contexts also introduce constraints on bio merging; the block layer
|
||||
needs to be aware of these constraints.
|
||||
|
||||
- We need a way for upper layers like filesystems to specify an encryption
|
||||
context to use for en/decrypting a struct bio, and a device driver (like UFS)
|
||||
needs to be able to use that encryption context when it processes the bio.
|
||||
- Different inline encryption hardware has different supported algorithms,
|
||||
supported data unit sizes, maximum data unit numbers, etc. We call these
|
||||
properties the "crypto capabilities". We need a way for device drivers to
|
||||
advertise crypto capabilities to upper layers in a generic way.
|
||||
|
||||
- We need a way for device drivers to expose their inline encryption
|
||||
capabilities in a unified way to the upper layers.
|
||||
- Inline encryption hardware usually (but not always) requires that keys be
|
||||
programmed into keyslots before being used. Since programming keyslots may be
|
||||
slow and there may not be very many keyslots, we shouldn't just program the
|
||||
key for every I/O request, but rather keep track of which keys are in the
|
||||
keyslots and reuse an already-programmed keyslot when possible.
|
||||
|
||||
- Upper layers typically define a specific end-of-life for crypto keys, e.g.
|
||||
when an encrypted directory is locked or when a crypto mapping is torn down.
|
||||
At these times, keys are wiped from memory. We must provide a way for upper
|
||||
layers to also evict keys from any keyslots they are present in.
|
||||
|
||||
Design
|
||||
======
|
||||
- When possible, device-mapper devices must be able to pass through the inline
|
||||
encryption support of their underlying devices. However, it doesn't make
|
||||
sense for device-mapper devices to have keyslots themselves.
|
||||
|
||||
We add a struct bio_crypt_ctx to struct bio that can
|
||||
represent an encryption context, because we need to be able to pass this
|
||||
encryption context from the upper layers (like the fs layer) to the
|
||||
device driver to act upon.
|
||||
Basic design
|
||||
============
|
||||
|
||||
While IE hardware works on the notion of keyslots, the FS layer has no
|
||||
knowledge of keyslots - it simply wants to specify an encryption context to
|
||||
use while en/decrypting a bio.
|
||||
We introduce ``struct blk_crypto_key`` to represent an inline encryption key and
|
||||
how it will be used. This includes the actual bytes of the key; the size of the
|
||||
key; the algorithm and data unit size the key will be used with; and the number
|
||||
of bytes needed to represent the maximum data unit number the key will be used
|
||||
with.
|
||||
|
||||
We introduce a keyslot manager (KSM) that handles the translation from
|
||||
encryption contexts specified by the FS to keyslots on the IE hardware.
|
||||
This KSM also serves as the way IE hardware can expose its capabilities to
|
||||
upper layers. The generic mode of operation is: each device driver that wants
|
||||
to support IE will construct a KSM and set it up in its struct request_queue.
|
||||
Upper layers that want to use IE on this device can then use this KSM in
|
||||
the device's struct request_queue to translate an encryption context into
|
||||
a keyslot. The presence of the KSM in the request queue shall be used to mean
|
||||
that the device supports IE.
|
||||
We introduce ``struct bio_crypt_ctx`` to represent an encryption context. It
|
||||
contains a data unit number and a pointer to a blk_crypto_key. We add pointers
|
||||
to a bio_crypt_ctx to ``struct bio`` and ``struct request``; this allows users
|
||||
of the block layer (e.g. filesystems) to provide an encryption context when
|
||||
creating a bio and have it be passed down the stack for processing by the block
|
||||
layer and device drivers. Note that the encryption context doesn't explicitly
|
||||
say whether to encrypt or decrypt, as that is implicit from the direction of the
|
||||
bio; WRITE means encrypt, and READ means decrypt.
|
||||
|
||||
The KSM uses refcounts to track which keyslots are idle (either they have no
|
||||
encryption context programmed, or there are no in-flight struct bios
|
||||
referencing that keyslot). When a new encryption context needs a keyslot, it
|
||||
tries to find a keyslot that has already been programmed with the same
|
||||
encryption context, and if there is no such keyslot, it evicts the least
|
||||
recently used idle keyslot and programs the new encryption context into that
|
||||
one. If no idle keyslots are available, then the caller will sleep until there
|
||||
is at least one.
|
||||
We also introduce ``struct blk_crypto_profile`` to contain all generic inline
|
||||
encryption-related state for a particular inline encryption device. The
|
||||
blk_crypto_profile serves as the way that drivers for inline encryption hardware
|
||||
advertise their crypto capabilities and provide certain functions (e.g.,
|
||||
functions to program and evict keys) to upper layers. Each device driver that
|
||||
wants to support inline encryption will construct a blk_crypto_profile, then
|
||||
associate it with the disk's request_queue.
|
||||
|
||||
The blk_crypto_profile also manages the hardware's keyslots, when applicable.
|
||||
This happens in the block layer, so that users of the block layer can just
|
||||
specify encryption contexts and don't need to know about keyslots at all, nor do
|
||||
device drivers need to care about most details of keyslot management.
|
||||
|
||||
blk-mq changes, other block layer changes and blk-crypto-fallback
|
||||
=================================================================
|
||||
Specifically, for each keyslot, the block layer (via the blk_crypto_profile)
|
||||
keeps track of which blk_crypto_key that keyslot contains (if any), and how many
|
||||
in-flight I/O requests are using it. When the block layer creates a
|
||||
``struct request`` for a bio that has an encryption context, it grabs a keyslot
|
||||
that already contains the key if possible. Otherwise it waits for an idle
|
||||
keyslot (a keyslot that isn't in-use by any I/O), then programs the key into the
|
||||
least-recently-used idle keyslot using the function the device driver provided.
|
||||
In both cases, the resulting keyslot is stored in the ``crypt_keyslot`` field of
|
||||
the request, where it is then accessible to device drivers and is released after
|
||||
the request completes.
|
||||
|
||||
We add a pointer to a ``bi_crypt_context`` and ``keyslot`` to
|
||||
struct request. These will be referred to as the ``crypto fields``
|
||||
for the request. This ``keyslot`` is the keyslot into which the
|
||||
``bi_crypt_context`` has been programmed in the KSM of the ``request_queue``
|
||||
that this request is being sent to.
|
||||
``struct request`` also contains a pointer to the original bio_crypt_ctx.
|
||||
Requests can be built from multiple bios, and the block layer must take the
|
||||
encryption context into account when trying to merge bios and requests. For two
|
||||
bios/requests to be merged, they must have compatible encryption contexts: both
|
||||
unencrypted, or both encrypted with the same key and contiguous data unit
|
||||
numbers. Only the encryption context for the first bio in a request is
|
||||
retained, since the remaining bios have been verified to be merge-compatible
|
||||
with the first bio.
|
||||
|
||||
We introduce ``block/blk-crypto-fallback.c``, which allows upper layers to remain
|
||||
blissfully unaware of whether or not real inline encryption hardware is present
|
||||
underneath. When a bio is submitted with a target ``request_queue`` that doesn't
|
||||
support the encryption context specified with the bio, the block layer will
|
||||
en/decrypt the bio with the blk-crypto-fallback.
|
||||
To make it possible for inline encryption to work with request_queue based
|
||||
layered devices, when a request is cloned, its encryption context is cloned as
|
||||
well. When the cloned request is submitted, it is then processed as usual; this
|
||||
includes getting a keyslot from the clone's target device if needed.
|
||||
|
||||
If the bio is a ``WRITE`` bio, a bounce bio is allocated, and the data in the bio
|
||||
is encrypted stored in the bounce bio - blk-mq will then proceed to process the
|
||||
bounce bio as if it were not encrypted at all (except when blk-integrity is
|
||||
concerned). ``blk-crypto-fallback`` sets the bounce bio's ``bi_end_io`` to an
|
||||
internal function that cleans up the bounce bio and ends the original bio.
|
||||
blk-crypto-fallback
|
||||
===================
|
||||
|
||||
If the bio is a ``READ`` bio, the bio's ``bi_end_io`` (and also ``bi_private``)
|
||||
is saved and overwritten by ``blk-crypto-fallback`` to
|
||||
``bio_crypto_fallback_decrypt_bio``. The bio's ``bi_crypt_context`` is also
|
||||
overwritten with ``NULL``, so that to the rest of the stack, the bio looks
|
||||
as if it was a regular bio that never had an encryption context specified.
|
||||
``bio_crypto_fallback_decrypt_bio`` will decrypt the bio, restore the original
|
||||
``bi_end_io`` (and also ``bi_private``) and end the bio again.
|
||||
It is desirable for the inline encryption support of upper layers (e.g.
|
||||
filesystems) to be testable without real inline encryption hardware, and
|
||||
likewise for the block layer's keyslot management logic. It is also desirable
|
||||
to allow upper layers to just always use inline encryption rather than have to
|
||||
implement encryption in multiple ways.
|
||||
|
||||
Regardless of whether real inline encryption hardware is used or the
|
||||
Therefore, we also introduce *blk-crypto-fallback*, which is an implementation
|
||||
of inline encryption using the kernel crypto API. blk-crypto-fallback is built
|
||||
into the block layer, so it works on any block device without any special setup.
|
||||
Essentially, when a bio with an encryption context is submitted to a
|
||||
request_queue that doesn't support that encryption context, the block layer will
|
||||
handle en/decryption of the bio using blk-crypto-fallback.
|
||||
|
||||
For encryption, the data cannot be encrypted in-place, as callers usually rely
|
||||
on it being unmodified. Instead, blk-crypto-fallback allocates bounce pages,
|
||||
fills a new bio with those bounce pages, encrypts the data into those bounce
|
||||
pages, and submits that "bounce" bio. When the bounce bio completes,
|
||||
blk-crypto-fallback completes the original bio. If the original bio is too
|
||||
large, multiple bounce bios may be required; see the code for details.
|
||||
|
||||
For decryption, blk-crypto-fallback "wraps" the bio's completion callback
|
||||
(``bi_complete``) and private data (``bi_private``) with its own, unsets the
|
||||
bio's encryption context, then submits the bio. If the read completes
|
||||
successfully, blk-crypto-fallback restores the bio's original completion
|
||||
callback and private data, then decrypts the bio's data in-place using the
|
||||
kernel crypto API. Decryption happens from a workqueue, as it may sleep.
|
||||
Afterwards, blk-crypto-fallback completes the bio.
|
||||
|
||||
In both cases, the bios that blk-crypto-fallback submits no longer have an
|
||||
encryption context. Therefore, lower layers only see standard unencrypted I/O.
|
||||
|
||||
blk-crypto-fallback also defines its own blk_crypto_profile and has its own
|
||||
"keyslots"; its keyslots contain ``struct crypto_skcipher`` objects. The reason
|
||||
for this is twofold. First, it allows the keyslot management logic to be tested
|
||||
without actual inline encryption hardware. Second, similar to actual inline
|
||||
encryption hardware, the crypto API doesn't accept keys directly in requests but
|
||||
rather requires that keys be set ahead of time, and setting keys can be
|
||||
expensive; moreover, allocating a crypto_skcipher can't happen on the I/O path
|
||||
at all due to the locks it takes. Therefore, the concept of keyslots still
|
||||
makes sense for blk-crypto-fallback.
|
||||
|
||||
Note that regardless of whether real inline encryption hardware or
|
||||
blk-crypto-fallback is used, the ciphertext written to disk (and hence the
|
||||
on-disk format of data) will be the same (assuming the hardware's implementation
|
||||
of the algorithm being used adheres to spec and functions correctly).
|
||||
|
||||
If a ``request queue``'s inline encryption hardware claimed to support the
|
||||
encryption context specified with a bio, then it will not be handled by the
|
||||
``blk-crypto-fallback``. We will eventually reach a point in blk-mq when a
|
||||
struct request needs to be allocated for that bio. At that point,
|
||||
blk-mq tries to program the encryption context into the ``request_queue``'s
|
||||
keyslot_manager, and obtain a keyslot, which it stores in its newly added
|
||||
``keyslot`` field. This keyslot is released when the request is completed.
|
||||
|
||||
When the first bio is added to a request, ``blk_crypto_rq_bio_prep`` is called,
|
||||
which sets the request's ``crypt_ctx`` to a copy of the bio's
|
||||
``bi_crypt_context``. bio_crypt_do_front_merge is called whenever a subsequent
|
||||
bio is merged to the front of the request, which updates the ``crypt_ctx`` of
|
||||
the request so that it matches the newly merged bio's ``bi_crypt_context``. In particular, the request keeps a copy of the ``bi_crypt_context`` of the first
|
||||
bio in its bio-list (blk-mq needs to be careful to maintain this invariant
|
||||
during bio and request merges).
|
||||
|
||||
To make it possible for inline encryption to work with request queue based
|
||||
layered devices, when a request is cloned, its ``crypto fields`` are cloned as
|
||||
well. When the cloned request is submitted, blk-mq programs the
|
||||
``bi_crypt_context`` of the request into the clone's request_queue's keyslot
|
||||
manager, and stores the returned keyslot in the clone's ``keyslot``.
|
||||
on-disk format of data) will be the same (assuming that both the inline
|
||||
encryption hardware's implementation and the kernel crypto API's implementation
|
||||
of the algorithm being used adhere to spec and function correctly).
|
||||
|
||||
blk-crypto-fallback is optional and is controlled by the
|
||||
``CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK`` kernel configuration option.
|
||||
|
||||
API presented to users of the block layer
|
||||
=========================================
|
||||
|
||||
``struct blk_crypto_key`` represents a crypto key (the raw key, size of the
|
||||
key, the crypto algorithm to use, the data unit size to use, and the number of
|
||||
bytes required to represent data unit numbers that will be specified with the
|
||||
``bi_crypt_context``).
|
||||
``blk_crypto_config_supported()`` allows users to check ahead of time whether
|
||||
inline encryption with particular crypto settings will work on a particular
|
||||
request_queue -- either via hardware or via blk-crypto-fallback. This function
|
||||
takes in a ``struct blk_crypto_config`` which is like blk_crypto_key, but omits
|
||||
the actual bytes of the key and instead just contains the algorithm, data unit
|
||||
size, etc. This function can be useful if blk-crypto-fallback is disabled.
|
||||
|
||||
``blk_crypto_init_key`` allows upper layers to initialize such a
|
||||
``blk_crypto_key``.
|
||||
``blk_crypto_init_key()`` allows users to initialize a blk_crypto_key.
|
||||
|
||||
``bio_crypt_set_ctx`` should be called on any bio that a user of
|
||||
the block layer wants en/decrypted via inline encryption (or the
|
||||
blk-crypto-fallback, if hardware support isn't available for the desired
|
||||
crypto configuration). This function takes the ``blk_crypto_key`` and the
|
||||
data unit number (DUN) to use when en/decrypting the bio.
|
||||
Users must call ``blk_crypto_start_using_key()`` before actually starting to use
|
||||
a blk_crypto_key on a request_queue (even if ``blk_crypto_config_supported()``
|
||||
was called earlier). This is needed to initialize blk-crypto-fallback if it
|
||||
will be needed. This must not be called from the data path, as this may have to
|
||||
allocate resources, which may deadlock in that case.
|
||||
|
||||
``blk_crypto_config_supported`` allows upper layers to query whether or not the
|
||||
an encryption context passed to request queue can be handled by blk-crypto
|
||||
(either by real inline encryption hardware, or by the blk-crypto-fallback).
|
||||
This is useful e.g. when blk-crypto-fallback is disabled, and the upper layer
|
||||
wants to use an algorithm that may not supported by hardware - this function
|
||||
lets the upper layer know ahead of time that the algorithm isn't supported,
|
||||
and the upper layer can fallback to something else if appropriate.
|
||||
Next, to attach an encryption context to a bio, users should call
|
||||
``bio_crypt_set_ctx()``. This function allocates a bio_crypt_ctx and attaches
|
||||
it to a bio, given the blk_crypto_key and the data unit number that will be used
|
||||
for en/decryption. Users don't need to worry about freeing the bio_crypt_ctx
|
||||
later, as that happens automatically when the bio is freed or reset.
|
||||
|
||||
``blk_crypto_start_using_key`` - Upper layers must call this function on
|
||||
``blk_crypto_key`` and a ``request_queue`` before using the key with any bio
|
||||
headed for that ``request_queue``. This function ensures that either the
|
||||
hardware supports the key's crypto settings, or the crypto API fallback has
|
||||
transforms for the needed mode allocated and ready to go. Note that this
|
||||
function may allocate an ``skcipher``, and must not be called from the data
|
||||
path, since allocating ``skciphers`` from the data path can deadlock.
|
||||
Finally, when done using inline encryption with a blk_crypto_key on a
|
||||
request_queue, users must call ``blk_crypto_evict_key()``. This ensures that
|
||||
the key is evicted from all keyslots it may be programmed into and unlinked from
|
||||
any kernel data structures it may be linked into.
|
||||
|
||||
``blk_crypto_evict_key`` *must* be called by upper layers before a
|
||||
``blk_crypto_key`` is freed. Further, it *must* only be called only once
|
||||
there are no more in-flight requests that use that ``blk_crypto_key``.
|
||||
``blk_crypto_evict_key`` will ensure that a key is removed from any keyslots in
|
||||
inline encryption hardware that the key might have been programmed into (or the blk-crypto-fallback).
|
||||
In summary, for users of the block layer, the lifecycle of a blk_crypto_key is
|
||||
as follows:
|
||||
|
||||
1. ``blk_crypto_config_supported()`` (optional)
|
||||
2. ``blk_crypto_init_key()``
|
||||
3. ``blk_crypto_start_using_key()``
|
||||
4. ``bio_crypt_set_ctx()`` (potentially many times)
|
||||
5. ``blk_crypto_evict_key()`` (after all I/O has completed)
|
||||
6. Zeroize the blk_crypto_key (this has no dedicated function)
|
||||
|
||||
If a blk_crypto_key is being used on multiple request_queues, then
|
||||
``blk_crypto_config_supported()`` (if used), ``blk_crypto_start_using_key()``,
|
||||
and ``blk_crypto_evict_key()`` must be called on each request_queue.
|
||||
|
||||
API presented to device drivers
|
||||
===============================
|
||||
|
||||
A :c:type:``struct blk_keyslot_manager`` should be set up by device drivers in
|
||||
the ``request_queue`` of the device. The device driver needs to call
|
||||
``blk_ksm_init`` (or its resource-managed variant ``devm_blk_ksm_init``) on the
|
||||
``blk_keyslot_manager``, while specifying the number of keyslots supported by
|
||||
the hardware.
|
||||
A device driver that wants to support inline encryption must set up a
|
||||
blk_crypto_profile in the request_queue of its device. To do this, it first
|
||||
must call ``blk_crypto_profile_init()`` (or its resource-managed variant
|
||||
``devm_blk_crypto_profile_init()``), providing the number of keyslots.
|
||||
|
||||
The device driver also needs to tell the KSM how to actually manipulate the
|
||||
IE hardware in the device to do things like programming the crypto key into
|
||||
the IE hardware into a particular keyslot. All this is achieved through the
|
||||
struct blk_ksm_ll_ops field in the KSM that the device driver
|
||||
must fill up after initing the ``blk_keyslot_manager``.
|
||||
Next, it must advertise its crypto capabilities by setting fields in the
|
||||
blk_crypto_profile, e.g. ``modes_supported`` and ``max_dun_bytes_supported``.
|
||||
|
||||
The KSM also handles runtime power management for the device when applicable
|
||||
(e.g. when it wants to program a crypto key into the IE hardware, the device
|
||||
must be runtime powered on) - so the device driver must also set the ``dev``
|
||||
field in the ksm to point to the `struct device` for the KSM to use for runtime
|
||||
power management.
|
||||
It then must set function pointers in the ``ll_ops`` field of the
|
||||
blk_crypto_profile to tell upper layers how to control the inline encryption
|
||||
hardware, e.g. how to program and evict keyslots. Most drivers will need to
|
||||
implement ``keyslot_program`` and ``keyslot_evict``. For details, see the
|
||||
comments for ``struct blk_crypto_ll_ops``.
|
||||
|
||||
``blk_ksm_reprogram_all_keys`` can be called by device drivers if the device
|
||||
needs each and every of its keyslots to be reprogrammed with the key it
|
||||
"should have" at the point in time when the function is called. This is useful
|
||||
e.g. if a device loses all its keys on runtime power down/up.
|
||||
Once the driver registers a blk_crypto_profile with a request_queue, I/O
|
||||
requests the driver receives via that queue may have an encryption context. All
|
||||
encryption contexts will be compatible with the crypto capabilities declared in
|
||||
the blk_crypto_profile, so drivers don't need to worry about handling
|
||||
unsupported requests. Also, if a nonzero number of keyslots was declared in the
|
||||
blk_crypto_profile, then all I/O requests that have an encryption context will
|
||||
also have a keyslot which was already programmed with the appropriate key.
|
||||
|
||||
If the driver used ``blk_ksm_init`` instead of ``devm_blk_ksm_init``, then
|
||||
``blk_ksm_destroy`` should be called to free up all resources used by a
|
||||
``blk_keyslot_manager`` once it is no longer needed.
|
||||
If the driver implements runtime suspend and its blk_crypto_ll_ops don't work
|
||||
while the device is runtime-suspended, then the driver must also set the ``dev``
|
||||
field of the blk_crypto_profile to point to the ``struct device`` that will be
|
||||
resumed before any of the low-level operations are called.
|
||||
|
||||
If there are situations where the inline encryption hardware loses the contents
|
||||
of its keyslots, e.g. device resets, the driver must handle reprogramming the
|
||||
keyslots. To do this, the driver may call ``blk_crypto_reprogram_all_keys()``.
|
||||
|
||||
Finally, if the driver used ``blk_crypto_profile_init()`` instead of
|
||||
``devm_blk_crypto_profile_init()``, then it is responsible for calling
|
||||
``blk_crypto_profile_destroy()`` when the crypto profile is no longer needed.
|
||||
|
||||
Layered Devices
|
||||
===============
|
||||
|
||||
Request queue based layered devices like dm-rq that wish to support IE need to
|
||||
create their own keyslot manager for their request queue, and expose whatever
|
||||
functionality they choose. When a layered device wants to pass a clone of that
|
||||
request to another ``request_queue``, blk-crypto will initialize and prepare the
|
||||
clone as necessary - see ``blk_crypto_insert_cloned_request`` in
|
||||
``blk-crypto.c``.
|
||||
|
||||
|
||||
Future Optimizations for layered devices
|
||||
========================================
|
||||
|
||||
Creating a keyslot manager for a layered device uses up memory for each
|
||||
keyslot, and in general, a layered device merely passes the request on to a
|
||||
"child" device, so the keyslots in the layered device itself are completely
|
||||
unused, and don't need any refcounting or keyslot programming. We can instead
|
||||
define a new type of KSM; the "passthrough KSM", that layered devices can use
|
||||
to advertise an unlimited number of keyslots, and support for any encryption
|
||||
algorithms they choose, while not actually using any memory for each keyslot.
|
||||
Another use case for the "passthrough KSM" is for IE devices that do not have a
|
||||
limited number of keyslots.
|
||||
|
||||
Request queue based layered devices like dm-rq that wish to support inline
|
||||
encryption need to create their own blk_crypto_profile for their request_queue,
|
||||
and expose whatever functionality they choose. When a layered device wants to
|
||||
pass a clone of that request to another request_queue, blk-crypto will
|
||||
initialize and prepare the clone as necessary; see
|
||||
``blk_crypto_insert_cloned_request()``.
|
||||
|
||||
Interaction between inline encryption and blk integrity
|
||||
=======================================================
|
||||
|
|
@ -257,7 +298,7 @@ Because there isn't any real hardware yet, it seems prudent to assume that
|
|||
hardware implementations might not implement both features together correctly,
|
||||
and disallow the combination for now. Whenever a device supports integrity, the
|
||||
kernel will pretend that the device does not support hardware inline encryption
|
||||
(by essentially setting the keyslot manager in the request_queue of the device
|
||||
to NULL). When the crypto API fallback is enabled, this means that all bios with
|
||||
and encryption context will use the fallback, and IO will complete as usual.
|
||||
When the fallback is disabled, a bio with an encryption context will be failed.
|
||||
(by setting the blk_crypto_profile in the request_queue of the device to NULL).
|
||||
When the crypto API fallback is enabled, this means that all bios with and
|
||||
encryption context will use the fallback, and IO will complete as usual. When
|
||||
the fallback is disabled, a bio with an encryption context will be failed.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Queue sysfs files
|
|||
|
||||
This text file will detail the queue files that are located in the sysfs tree
|
||||
for each block device. Note that stacked devices typically do not export
|
||||
any settings, since their queue merely functions are a remapping target.
|
||||
any settings, since their queue merely functions as a remapping target.
|
||||
These files are the ones found in the /sys/block/xxx/queue/ directory.
|
||||
|
||||
Files denoted with a RO postfix are readonly and the RW postfix means
|
||||
|
|
@ -286,4 +286,35 @@ sequential zones of zoned block devices (devices with a zoned attributed
|
|||
that reports "host-managed" or "host-aware"). This value is always 0 for
|
||||
regular block devices.
|
||||
|
||||
independent_access_ranges (RO)
|
||||
------------------------------
|
||||
|
||||
The presence of this sub-directory of the /sys/block/xxx/queue/ directory
|
||||
indicates that the device is capable of executing requests targeting
|
||||
different sector ranges in parallel. For instance, single LUN multi-actuator
|
||||
hard-disks will have an independent_access_ranges directory if the device
|
||||
correctly advertizes the sector ranges of its actuators.
|
||||
|
||||
The independent_access_ranges directory contains one directory per access
|
||||
range, with each range described using the sector (RO) attribute file to
|
||||
indicate the first sector of the range and the nr_sectors (RO) attribute file
|
||||
to indicate the total number of sectors in the range starting from the first
|
||||
sector of the range. For example, a dual-actuator hard-disk will have the
|
||||
following independent_access_ranges entries.::
|
||||
|
||||
$ tree /sys/block/<device>/queue/independent_access_ranges/
|
||||
/sys/block/<device>/queue/independent_access_ranges/
|
||||
|-- 0
|
||||
| |-- nr_sectors
|
||||
| `-- sector
|
||||
`-- 1
|
||||
|-- nr_sectors
|
||||
`-- sector
|
||||
|
||||
The sector and nr_sectors attributes use 512B sector unit, regardless of
|
||||
the actual block size of the device. Independent access ranges do not
|
||||
overlap and include all sectors within the device capacity. The access
|
||||
ranges are numbered in increasing order of the range start sector,
|
||||
that is, the sector attribute of range 0 always has the value 0.
|
||||
|
||||
Jens Axboe <jens.axboe@oracle.com>, February 2009
|
||||
|
|
|
|||
|
|
@ -907,6 +907,17 @@ commands can be identified by the underscores in their names.
|
|||
specifies the slot for which the information is given. The special
|
||||
value *CDSL_CURRENT* requests that information about the currently
|
||||
selected slot be returned.
|
||||
`CDROM_TIMED_MEDIA_CHANGE`
|
||||
Checks whether the disc has been changed since a user supplied time
|
||||
and returns the time of the last disc change.
|
||||
|
||||
*arg* is a pointer to a *cdrom_timed_media_change_info* struct.
|
||||
*arg->last_media_change* may be set by calling code to signal
|
||||
the timestamp of the last known media change (by the caller).
|
||||
Upon successful return, this ioctl call will set
|
||||
*arg->last_media_change* to the latest media change timestamp (in ms)
|
||||
known by the kernel/driver and set *arg->has_changed* to 1 if
|
||||
that timestamp is more recent than the timestamp set by the caller.
|
||||
`CDROM_DRIVE_STATUS`
|
||||
Returns the status of the drive by a call to
|
||||
*drive_status()*. Return values are defined in cdrom_drive_status_.
|
||||
|
|
|
|||
|
|
@ -326,6 +326,12 @@ maps this page at its virtual address.
|
|||
dirty. Again, see sparc64 for examples of how
|
||||
to deal with this.
|
||||
|
||||
``void flush_dcache_folio(struct folio *folio)``
|
||||
This function is called under the same circumstances as
|
||||
flush_dcache_page(). It allows the architecture to
|
||||
optimise for flushing the entire folio of pages instead
|
||||
of flushing one page at a time.
|
||||
|
||||
``void copy_to_user_page(struct vm_area_struct *vma, struct page *page,
|
||||
unsigned long user_vaddr, void *dst, void *src, int len)``
|
||||
``void copy_from_user_page(struct vm_area_struct *vma, struct page *page,
|
||||
|
|
|
|||
|
|
@ -67,9 +67,6 @@ variety of methods:
|
|||
deprecated
|
||||
- generic_handle_domain_irq() handles an interrupt described by a
|
||||
domain and a hwirq number
|
||||
- handle_domain_irq() does the same thing for root interrupt
|
||||
controllers and deals with the set_irq_reg()/irq_enter() sequences
|
||||
that most architecture requires
|
||||
|
||||
Note that irq domain lookups must happen in contexts that are
|
||||
compatible with a RCU read-side critical section.
|
||||
|
|
|
|||
|
|
@ -95,6 +95,11 @@ More Memory Management Functions
|
|||
.. kernel-doc:: mm/mempolicy.c
|
||||
.. kernel-doc:: include/linux/mm_types.h
|
||||
:internal:
|
||||
.. kernel-doc:: include/linux/mm_inline.h
|
||||
.. kernel-doc:: include/linux/page-flags.h
|
||||
.. kernel-doc:: include/linux/mm.h
|
||||
:internal:
|
||||
.. kernel-doc:: include/linux/page_ref.h
|
||||
.. kernel-doc:: include/linux/mmzone.h
|
||||
.. kernel-doc:: mm/util.c
|
||||
:functions: folio_mapping
|
||||
|
|
|
|||
|
|
@ -69,6 +69,8 @@ the crypto engine via one of:
|
|||
|
||||
* crypto_transfer_hash_request_to_engine()
|
||||
|
||||
* crypto_transfer_kpp_request_to_engine()
|
||||
|
||||
* crypto_transfer_skcipher_request_to_engine()
|
||||
|
||||
At the end of the request process, a call to one of the following functions is needed:
|
||||
|
|
@ -79,4 +81,6 @@ At the end of the request process, a call to one of the following functions is n
|
|||
|
||||
* crypto_finalize_hash_request()
|
||||
|
||||
* crypto_finalize_kpp_request()
|
||||
|
||||
* crypto_finalize_skcipher_request()
|
||||
|
|
|
|||
|
|
@ -194,14 +194,17 @@ additional boot parameters that allow disabling KASAN or controlling features:
|
|||
|
||||
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
|
||||
|
||||
- ``kasan.mode=sync`` or ``=async`` controls whether KASAN is configured in
|
||||
synchronous or asynchronous mode of execution (default: ``sync``).
|
||||
- ``kasan.mode=sync``, ``=async`` or ``=asymm`` controls whether KASAN
|
||||
is configured in synchronous, asynchronous or asymmetric mode of
|
||||
execution (default: ``sync``).
|
||||
Synchronous mode: a bad access is detected immediately when a tag
|
||||
check fault occurs.
|
||||
Asynchronous mode: a bad access detection is delayed. When a tag check
|
||||
fault occurs, the information is stored in hardware (in the TFSR_EL1
|
||||
register for arm64). The kernel periodically checks the hardware and
|
||||
only reports tag faults during these checks.
|
||||
Asymmetric mode: a bad access is detected synchronously on reads and
|
||||
asynchronously on writes.
|
||||
|
||||
- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack
|
||||
traces collection (default: ``on``).
|
||||
|
|
|
|||
|
|
@ -1,49 +0,0 @@
|
|||
Binding for Samsung S2M and S5M family clock generator block
|
||||
============================================================
|
||||
|
||||
This is a part of device tree bindings for S2M and S5M family multi-function
|
||||
devices.
|
||||
More information can be found in bindings/mfd/sec-core.txt file.
|
||||
|
||||
The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz
|
||||
outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs.
|
||||
|
||||
To register these as clocks with common clock framework instantiate under
|
||||
main device node a sub-node named "clocks".
|
||||
|
||||
It uses the common clock binding documented in:
|
||||
- Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
|
||||
Required properties of the "clocks" sub-node:
|
||||
- #clock-cells: should be 1.
|
||||
- compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk",
|
||||
"samsung,s2mps14-clk", "samsung,s5m8767-clk"
|
||||
The S2MPS15 uses the same compatible as S2MPS13, as both provides similar
|
||||
clocks.
|
||||
|
||||
|
||||
Each clock is assigned an identifier and client nodes use this identifier
|
||||
to specify the clock which they consume.
|
||||
Clock ID Devices
|
||||
----------------------------------------------------------
|
||||
32KhzAP 0 S2MPS11/13/14/15, S5M8767
|
||||
32KhzCP 1 S2MPS11/13/15, S5M8767
|
||||
32KhzBT 2 S2MPS11/13/14/15, S5M8767
|
||||
|
||||
Include dt-bindings/clock/samsung,s2mps11.h file to use preprocessor defines
|
||||
in device tree sources.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
s2mps11_pmic@66 {
|
||||
compatible = "samsung,s2mps11-pmic";
|
||||
reg = <0x66>;
|
||||
|
||||
s2m_osc: clocks {
|
||||
compatible = "samsung,s2mps11-clk";
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "xx", "yy", "zz";
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/samsung,s2mps11.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S2M and S5M family clock generator block
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
description: |
|
||||
This is a part of device tree bindings for S2M and S5M family of Power
|
||||
Management IC (PMIC).
|
||||
|
||||
The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz
|
||||
outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs.
|
||||
|
||||
All available clocks are defined as preprocessor macros in
|
||||
dt-bindings/clock/samsung,s2mps11.h header.
|
||||
|
||||
See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
|
||||
additional information and example.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- samsung,s2mps11-clk
|
||||
- samsung,s2mps13-clk # S2MPS13 and S2MPS15
|
||||
- samsung,s2mps14-clk
|
||||
- samsung,s5m8767-clk
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
clock-output-names:
|
||||
minItems: 3
|
||||
maxItems: 3
|
||||
description: Names for AP, CP and BT clocks.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/crypto/intel,keembay-ocs-ecc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Intel Keem Bay OCS ECC Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Daniele Alessandrelli <daniele.alessandrelli@intel.com>
|
||||
- Prabhjot Khurana <prabhjot.khurana@intel.com>
|
||||
|
||||
description:
|
||||
The Intel Keem Bay Offload and Crypto Subsystem (OCS) Elliptic Curve
|
||||
Cryptography (ECC) device provides hardware acceleration for elliptic curve
|
||||
cryptography using the NIST P-256 and NIST P-384 elliptic curves.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: intel,keembay-ocs-ecc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
crypto@30001000 {
|
||||
compatible = "intel,keembay-ocs-ecc";
|
||||
reg = <0x30001000 0x1000>;
|
||||
interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&scmi_clk 95>;
|
||||
};
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
Bindings for Delta Electronics DPS-650-AB power supply
|
||||
|
||||
Required properties:
|
||||
- compatible : "delta,dps650ab"
|
||||
- reg : I2C address, one of 0x58, 0x59.
|
||||
|
||||
Example:
|
||||
dps650ab@58 {
|
||||
compatible = "delta,dps650ab";
|
||||
reg = <0x58>;
|
||||
};
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
Honeywell Humidicon HIH-6130 humidity/temperature sensor
|
||||
--------------------------------------------------------
|
||||
|
||||
Requires node properties:
|
||||
- compatible : "honeywell,hi6130"
|
||||
- reg : the I2C address of the device. This is 0x27.
|
||||
|
||||
Example:
|
||||
hih6130@27 {
|
||||
compatible = "honeywell,hih6130";
|
||||
reg = <0x27>;
|
||||
};
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
Device-tree bindings for IBM Common Form Factor Power Supply Versions 1 and 2
|
||||
-----------------------------------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : Must be one of the following:
|
||||
"ibm,cffps1"
|
||||
"ibm,cffps2"
|
||||
or "ibm,cffps" if the system
|
||||
must support any version of the
|
||||
power supply
|
||||
- reg = < I2C bus address >; : Address of the power supply on the
|
||||
I2C bus.
|
||||
|
||||
Example:
|
||||
|
||||
i2c-bus@100 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
< more properties >
|
||||
|
||||
power-supply@68 {
|
||||
compatible = "ibm,cffps1";
|
||||
reg = <0x68>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: ADC-attached Hardware Sensor Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Jonathan Cameron <jic23@kernel.org>
|
||||
|
||||
description: >
|
||||
Bindings for hardware monitoring devices connected to ADC controllers
|
||||
supporting the Industrial I/O bindings.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: iio-hwmon
|
||||
|
||||
io-channels:
|
||||
minItems: 1
|
||||
maxItems: 8 # Should be enough
|
||||
description: >
|
||||
List of phandles to ADC channels to read the monitoring values
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- io-channels
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
iio-hwmon {
|
||||
compatible = "iio-hwmon";
|
||||
io-channels = <&adc 1>, <&adc 2>;
|
||||
};
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
Properties for Jedec JC-42.4 compatible temperature sensors
|
||||
|
||||
Required properties:
|
||||
- compatible: May include a device-specific string consisting of the
|
||||
manufacturer and the name of the chip. A list of supported
|
||||
chip names follows.
|
||||
Must include "jedec,jc-42.4-temp" for any Jedec JC-42.4
|
||||
compatible temperature sensor.
|
||||
|
||||
Supported chip names:
|
||||
adi,adt7408
|
||||
atmel,at30ts00
|
||||
atmel,at30tse004
|
||||
onnn,cat6095
|
||||
onnn,cat34ts02
|
||||
maxim,max6604
|
||||
microchip,mcp9804
|
||||
microchip,mcp9805
|
||||
microchip,mcp9808
|
||||
microchip,mcp98243
|
||||
microchip,mcp98244
|
||||
microchip,mcp9843
|
||||
nxp,se97
|
||||
nxp,se98
|
||||
st,stts2002
|
||||
st,stts2004
|
||||
st,stts3000
|
||||
st,stts424
|
||||
st,stts424e
|
||||
idt,tse2002
|
||||
idt,tse2004
|
||||
idt,ts3000
|
||||
idt,ts3001
|
||||
|
||||
- reg: I2C address
|
||||
|
||||
Optional properties:
|
||||
- smbus-timeout-disable: When set, the smbus timeout function will be disabled.
|
||||
This is not supported on all chips.
|
||||
|
||||
Example:
|
||||
|
||||
temp-sensor@1a {
|
||||
compatible = "jedec,jc-42.4-temp";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
|
|
@ -0,0 +1,78 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/jedec,jc42.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Jedec JC-42.4 compatible temperature sensors
|
||||
|
||||
maintainers:
|
||||
- Jean Delvare <jdelvare@suse.com>
|
||||
- Guenter Roeck <linux@roeck-us.net>
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
const: jedec,jc-42.4-temp
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: jedec,jc-42.4-temp
|
||||
- items:
|
||||
- enum:
|
||||
- adi,adt7408
|
||||
- atmel,at30ts00
|
||||
- atmel,at30tse004
|
||||
- idt,tse2002
|
||||
- idt,tse2004
|
||||
- idt,ts3000
|
||||
- idt,ts3001
|
||||
- maxim,max6604
|
||||
- microchip,mcp9804
|
||||
- microchip,mcp9805
|
||||
- microchip,mcp9808
|
||||
- microchip,mcp98243
|
||||
- microchip,mcp98244
|
||||
- microchip,mcp9843
|
||||
- nxp,se97
|
||||
- nxp,se97b
|
||||
- nxp,se98
|
||||
- onnn,cat6095
|
||||
- onnn,cat34ts02
|
||||
- st,stts2002
|
||||
- st,stts2004
|
||||
- st,stts3000
|
||||
- st,stts424
|
||||
- st,stts424e
|
||||
- const: jedec,jc-42.4-temp
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
smbus-timeout-disable:
|
||||
description: |
|
||||
When set, the smbus timeout function will be disabled. This is not
|
||||
supported on all chips.
|
||||
type: boolean
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
temp-sensor@1a {
|
||||
compatible = "jedec,jc-42.4-temp";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/lltc,ltc4151.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: LTC4151 High Voltage I2C Current and Voltage Monitor
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: lltc,ltc4151
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
shunt-resistor-micro-ohms:
|
||||
description:
|
||||
Shunt resistor value in micro-Ohms
|
||||
default: 1000
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
sensor@6e {
|
||||
compatible = "lltc,ltc4151";
|
||||
reg = <0x6e>;
|
||||
shunt-resistor-micro-ohms = <1500>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
* LM70/TMP121/LM71/LM74 thermometer.
|
||||
|
||||
Required properties:
|
||||
- compatible: one of
|
||||
"ti,lm70"
|
||||
"ti,tmp121"
|
||||
"ti,tmp122"
|
||||
"ti,lm71"
|
||||
"ti,lm74"
|
||||
|
||||
See Documentation/devicetree/bindings/spi/spi-bus.txt for more required and
|
||||
optional properties.
|
||||
|
||||
Example:
|
||||
|
||||
spi_master {
|
||||
temperature-sensor@0 {
|
||||
compatible = "ti,lm70";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <1000000>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
* LM90 series thermometer.
|
||||
|
||||
Required node properties:
|
||||
- compatible: manufacturer and chip name, one of
|
||||
"adi,adm1032"
|
||||
"adi,adt7461"
|
||||
"adi,adt7461a"
|
||||
"gmt,g781"
|
||||
"national,lm90"
|
||||
"national,lm86"
|
||||
"national,lm89"
|
||||
"national,lm99"
|
||||
"dallas,max6646"
|
||||
"dallas,max6647"
|
||||
"dallas,max6649"
|
||||
"dallas,max6657"
|
||||
"dallas,max6658"
|
||||
"dallas,max6659"
|
||||
"dallas,max6680"
|
||||
"dallas,max6681"
|
||||
"dallas,max6695"
|
||||
"dallas,max6696"
|
||||
"onnn,nct1008"
|
||||
"winbond,w83l771"
|
||||
"nxp,sa56004"
|
||||
"ti,tmp451"
|
||||
|
||||
- reg: I2C bus address of the device
|
||||
|
||||
- vcc-supply: vcc regulator for the supply voltage.
|
||||
|
||||
Optional properties:
|
||||
- interrupts: Contains a single interrupt specifier which describes the
|
||||
LM90 "-ALERT" pin output.
|
||||
See interrupt-controller/interrupts.txt for the format.
|
||||
|
||||
- #thermal-sensor-cells: should be set to 1. See thermal/thermal-sensor.yaml
|
||||
for details. See <include/dt-bindings/thermal/lm90.h> for the
|
||||
definition of the local, remote and 2nd remote sensor index
|
||||
constants.
|
||||
|
||||
Example LM90 node:
|
||||
|
||||
temp-sensor {
|
||||
compatible = "onnn,nct1008";
|
||||
reg = <0x4c>;
|
||||
vcc-supply = <&palmas_ldo6_reg>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>;
|
||||
#thermal-sensor-cells = <1>;
|
||||
}
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
LTC4151 High Voltage I2C Current and Voltage Monitor
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "lltc,ltc4151"
|
||||
- reg: I2C address
|
||||
|
||||
Optional properties:
|
||||
- shunt-resistor-micro-ohms
|
||||
Shunt resistor value in micro-Ohms
|
||||
Defaults to <1000> if unset.
|
||||
|
||||
Example:
|
||||
|
||||
ltc4151@6e {
|
||||
compatible = "lltc,ltc4151";
|
||||
reg = <0x6e>;
|
||||
shunt-resistor-micro-ohms = <1500>;
|
||||
};
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
mcp3021 properties
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be one of the following:
|
||||
- "microchip,mcp3021" for mcp3021
|
||||
- "microchip,mcp3221" for mcp3221
|
||||
- reg: I2C address
|
||||
|
||||
Optional properties:
|
||||
|
||||
- reference-voltage-microvolt
|
||||
Reference voltage in microvolt (uV)
|
||||
|
||||
Example:
|
||||
|
||||
mcp3021@4d {
|
||||
compatible = "microchip,mcp3021";
|
||||
reg = <0x4d>;
|
||||
|
||||
reference-voltage-microvolt = <4500000>; /* 4.5 V */
|
||||
};
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/microchip,mcp3021.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Microchip MCP3021 A/D converter
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- microchip,mcp3021
|
||||
- microchip,mcp3221
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
reference-voltage-microvolt:
|
||||
description:
|
||||
VDD supply power and reference voltage
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
adc@4d {
|
||||
compatible = "microchip,mcp3021";
|
||||
reg = <0x4d>;
|
||||
|
||||
reference-voltage-microvolt = <4500000>; /* 4.5 V */
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,78 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/national,lm90.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: LM90 series thermometer
|
||||
|
||||
maintainers:
|
||||
- Jean Delvare <jdelvare@suse.com>
|
||||
- Guenter Roeck <linux@roeck-us.net>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- adi,adm1032
|
||||
- adi,adt7461
|
||||
- adi,adt7461a
|
||||
- dallas,max6646
|
||||
- dallas,max6647
|
||||
- dallas,max6649
|
||||
- dallas,max6657
|
||||
- dallas,max6658
|
||||
- dallas,max6659
|
||||
- dallas,max6680
|
||||
- dallas,max6681
|
||||
- dallas,max6695
|
||||
- dallas,max6696
|
||||
- gmt,g781
|
||||
- national,lm86
|
||||
- national,lm89
|
||||
- national,lm90
|
||||
- national,lm99
|
||||
- nxp,sa56004
|
||||
- onnn,nct1008
|
||||
- ti,tmp451
|
||||
- winbond,w83l771
|
||||
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: |
|
||||
Single interrupt specifier which describes the LM90 "-ALERT" pin
|
||||
output.
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#thermal-sensor-cells":
|
||||
const: 1
|
||||
|
||||
vcc-supply:
|
||||
description: phandle to the regulator that provides the +VCC supply
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/tegra-gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
sensor@4c {
|
||||
compatible = "onnn,nct1008";
|
||||
reg = <0x4c>;
|
||||
vcc-supply = <&palmas_ldo6_reg>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>;
|
||||
#thermal-sensor-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,141 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/ntc-thermistor.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NTC thermistor temperature sensors
|
||||
|
||||
maintainers:
|
||||
- Naveen Krishna Chatradhi <ch.naveen@samsung.com>
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
|
||||
description: |
|
||||
Thermistors with negative temperature coefficient (NTC) are resistors that
|
||||
vary in resistance in an often non-linear way in relation to temperature.
|
||||
The negative temperature coefficient means that the resistance decreases
|
||||
as the temperature rises. Since the relationship between resistance and
|
||||
temperature is non-linear, software drivers most often need to use a look
|
||||
up table and interpolation to get from resistance to temperature.
|
||||
|
||||
When used in practice, a thermistor is often connected between ground, a
|
||||
pull-up resistor or/and a pull-down resistor and a fixed voltage like this:
|
||||
|
||||
+ e.g. 5V = pull-up voltage (puv)
|
||||
|
|
||||
+-+
|
||||
| |
|
||||
| | Pull-up resistor
|
||||
| | (puo)
|
||||
+-+
|
||||
|-------------------------o
|
||||
+-+ | ^
|
||||
| |/ |
|
||||
| / |
|
||||
|/| Thermistor | Measured voltage (mv)
|
||||
/ | | "connected ground"
|
||||
/| | |
|
||||
+-+ |
|
||||
|-------------------------o
|
||||
+-+ ^
|
||||
| | |
|
||||
| | Pull-down resistor | Measured voltage (mv)
|
||||
| | (pdo) | "connected positive"
|
||||
+-+ |
|
||||
| |
|
||||
| v
|
||||
+ GND GND
|
||||
|
||||
The arrangements of where we measure the voltage over the thermistor are
|
||||
called "connected ground" and "connected positive" and shall be understood as
|
||||
the cases when either pull-up or pull-down resistance is zero.
|
||||
|
||||
If the pull-up resistance is 0 one end of the thermistor is connected to the
|
||||
positive voltage and we get the thermistor on top of a pull-down resistor
|
||||
and we take the measure between the thermistor and the pull-down resistor.
|
||||
|
||||
Conversely if the pull-down resistance is zero, one end of the thermistor is
|
||||
connected to ground and we get the thermistor under the pull-up resistor
|
||||
and we take the measure between the pull-up resistor and the thermistor.
|
||||
|
||||
We can use both pull-up and pull-down resistors at the same time, and then
|
||||
the figure illustrates where the voltage will be measured for the "connected
|
||||
ground" and "connected positive" cases.
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
pattern: "^thermistor(.*)?$"
|
||||
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: epcos,b57330v2103
|
||||
- const: epcos,b57891s0103
|
||||
- const: murata,ncp15wb473
|
||||
- const: murata,ncp18wb473
|
||||
- const: murata,ncp21wb473
|
||||
- const: murata,ncp03wb473
|
||||
- const: murata,ncp15wl333
|
||||
- const: murata,ncp03wf104
|
||||
- const: murata,ncp15xh103
|
||||
# Deprecated "ntp," compatible strings
|
||||
- const: ntc,ncp15wb473
|
||||
deprecated: true
|
||||
- const: ntc,ncp18wb473
|
||||
deprecated: true
|
||||
- const: ntc,ncp21wb473
|
||||
deprecated: true
|
||||
- const: ntc,ncp03wb473
|
||||
deprecated: true
|
||||
- const: ntc,ncp15wl333
|
||||
deprecated: true
|
||||
|
||||
"#thermal-sensor-cells":
|
||||
description: Thermal sensor cells if used for thermal sensoring.
|
||||
const: 0
|
||||
|
||||
pullup-uv:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: Pull-up voltage in micro volts. Must always be specified.
|
||||
|
||||
pullup-ohm:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: Pull-up resistance in ohms. Must always be specified, even
|
||||
if zero.
|
||||
|
||||
pulldown-ohm:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: Pull-down resistance in ohms. Must always be specified, even
|
||||
if zero.
|
||||
|
||||
connected-positive:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description: Indicates how the thermistor is connected in series with
|
||||
a pull-up and/or a pull-down resistor. See the description above for
|
||||
an illustration. If this flag is NOT specified, the thermistor is assumed
|
||||
to be connected-ground, which usually means a pull-down resistance of
|
||||
zero but complex arrangements are possible.
|
||||
|
||||
# See /schemas/iio/adc/adc.yaml
|
||||
io-channels:
|
||||
maxItems: 1
|
||||
description: IIO ADC channel to read the voltage over the resistor. Must
|
||||
always be specified.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- pullup-uv
|
||||
- pullup-ohm
|
||||
- pulldown-ohm
|
||||
- io-channels
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
thermistor0 {
|
||||
compatible = "murata,ncp18wb473";
|
||||
io-channels = <&gpadc 0x06>;
|
||||
pullup-uv = <1800000>;
|
||||
pullup-ohm = <220000>;
|
||||
pulldown-ohm = <0>;
|
||||
#thermal-sensor-cells = <0>;
|
||||
};
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
NTC Thermistor hwmon sensors
|
||||
-------------------------------
|
||||
|
||||
Requires node properties:
|
||||
- "compatible" value : one of
|
||||
"epcos,b57330v2103"
|
||||
"epcos,b57891s0103"
|
||||
"murata,ncp15wb473"
|
||||
"murata,ncp18wb473"
|
||||
"murata,ncp21wb473"
|
||||
"murata,ncp03wb473"
|
||||
"murata,ncp15wl333"
|
||||
"murata,ncp03wf104"
|
||||
"murata,ncp15xh103"
|
||||
|
||||
/* Usage of vendor name "ntc" is deprecated */
|
||||
<DEPRECATED> "ntc,ncp15wb473"
|
||||
<DEPRECATED> "ntc,ncp18wb473"
|
||||
<DEPRECATED> "ntc,ncp21wb473"
|
||||
<DEPRECATED> "ntc,ncp03wb473"
|
||||
<DEPRECATED> "ntc,ncp15wl333"
|
||||
|
||||
- "pullup-uv" Pull up voltage in micro volts
|
||||
- "pullup-ohm" Pull up resistor value in ohms
|
||||
- "pulldown-ohm" Pull down resistor value in ohms
|
||||
- "connected-positive" Always ON, If not specified.
|
||||
Status change is possible.
|
||||
- "io-channels" Channel node of ADC to be used for
|
||||
conversion.
|
||||
|
||||
Optional node properties:
|
||||
- "#thermal-sensor-cells" Used to expose itself to thermal fw.
|
||||
|
||||
Read more about iio bindings at
|
||||
https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/
|
||||
|
||||
Example:
|
||||
ncp15wb473@0 {
|
||||
compatible = "murata,ncp15wb473";
|
||||
pullup-uv = <1800000>;
|
||||
pullup-ohm = <47000>;
|
||||
pulldown-ohm = <0>;
|
||||
io-channels = <&adc 3>;
|
||||
};
|
||||
|
|
@ -0,0 +1,145 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
|
||||
$id: http://devicetree.org/schemas/hwmon/nuvoton,nct7802.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Nuvoton NCT7802Y Hardware Monitoring IC
|
||||
|
||||
maintainers:
|
||||
- Guenter Roeck <linux@roeck-us.net>
|
||||
|
||||
description: |
|
||||
The NCT7802Y is a hardware monitor IC which supports one on-die and up to
|
||||
5 remote temperature sensors with SMBus interface.
|
||||
|
||||
Datasheets:
|
||||
https://www.nuvoton.com/export/resource-files/Nuvoton_NCT7802Y_Datasheet_V12.pdf
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- nuvoton,nct7802
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
"^channel@[0-3]$":
|
||||
type: object
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
reg:
|
||||
items:
|
||||
- enum:
|
||||
- 0 # Local Temperature Sensor ("LTD")
|
||||
- 1 # Remote Temperature Sensor or Voltage Sensor 1 ("RTD1")
|
||||
- 2 # Remote Temperature Sensor or Voltage Sensor 2 ("RTD2")
|
||||
- 3 # Remote Temperature Sensor or Voltage Sensor 3 ("RTD3")
|
||||
|
||||
sensor-type:
|
||||
items:
|
||||
- enum:
|
||||
- temperature
|
||||
- voltage
|
||||
|
||||
temperature-mode:
|
||||
items:
|
||||
- enum:
|
||||
- thermistor
|
||||
- thermal-diode
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
allOf:
|
||||
# For channels RTD1, RTD2 and RTD3, require sensor-type to be set.
|
||||
# Otherwise (for all other channels), do not allow temperature-mode to be
|
||||
# set.
|
||||
- if:
|
||||
properties:
|
||||
reg:
|
||||
items:
|
||||
- enum:
|
||||
- 1
|
||||
- 2
|
||||
- 3
|
||||
then:
|
||||
required:
|
||||
- sensor-type
|
||||
else:
|
||||
not:
|
||||
required:
|
||||
- sensor-type
|
||||
|
||||
# For channels RTD1 and RTD2 and if sensor-type is "temperature", require
|
||||
# temperature-mode to be set. Otherwise (for all other channels or
|
||||
# sensor-type settings), do not allow temperature-mode to be set
|
||||
- if:
|
||||
properties:
|
||||
reg:
|
||||
items:
|
||||
- enum:
|
||||
- 1
|
||||
- 2
|
||||
sensor-type:
|
||||
items:
|
||||
- enum:
|
||||
- temperature
|
||||
then:
|
||||
required:
|
||||
- temperature-mode
|
||||
else:
|
||||
not:
|
||||
required:
|
||||
- temperature-mode
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
nct7802@28 {
|
||||
compatible = "nuvoton,nct7802";
|
||||
reg = <0x28>;
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
channel@0 { /* LTD */
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
channel@1 { /* RTD1 */
|
||||
reg = <1>;
|
||||
sensor-type = "voltage";
|
||||
};
|
||||
|
||||
channel@2 { /* RTD2 */
|
||||
reg = <2>;
|
||||
sensor-type = "temperature";
|
||||
temperature-mode = "thermal-diode";
|
||||
};
|
||||
|
||||
channel@3 { /* RTD3 */
|
||||
reg = <3>;
|
||||
sensor-type = "temperature";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
|
||||
$id: http://devicetree.org/schemas/hwmon/pmbus/ti,lm25066.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: National Semiconductor/Texas Instruments LM250x6/LM506x power-management ICs
|
||||
|
||||
maintainers:
|
||||
- Zev Weiss <zev@bewilderbeest.net>
|
||||
|
||||
description: |
|
||||
The LM25066 family of power-management ICs (a.k.a. hot-swap
|
||||
controllers or eFuses in various contexts) are PMBus devices that
|
||||
offer temperature, current, voltage, and power monitoring.
|
||||
|
||||
Datasheet: https://www.ti.com/lit/ds/symlink/lm25066.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ti,lm25056
|
||||
- ti,lm25066
|
||||
- ti,lm5064
|
||||
- ti,lm5066
|
||||
- ti,lm5066i
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
shunt-resistor-micro-ohms:
|
||||
description:
|
||||
Shunt (sense) resistor value in micro-Ohms
|
||||
default: 1000
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
pmic@40 {
|
||||
compatible = "ti,lm25066";
|
||||
reg = <0x40>;
|
||||
shunt-resistor-micro-ohms = <675>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/sensirion,sht15.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Sensirion SHT15 humidity and temperature sensor
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: sensirion,sht15
|
||||
|
||||
clk-gpios:
|
||||
maxItems: 1
|
||||
|
||||
data-gpios:
|
||||
maxItems: 1
|
||||
|
||||
vcc-supply:
|
||||
description: regulator that drives the VCC pin
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clk-gpios
|
||||
- data-gpios
|
||||
- vcc-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
sensor {
|
||||
compatible = "sensirion,sht15";
|
||||
clk-gpios = <&gpio4 12 0>;
|
||||
data-gpios = <&gpio4 13 0>;
|
||||
vcc-supply = <®_sht15>;
|
||||
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_sensor>;
|
||||
};
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
Sensirion SHT15 Humidity and Temperature Sensor
|
||||
|
||||
Required properties:
|
||||
|
||||
- "compatible": must be "sensirion,sht15".
|
||||
- "data-gpios": GPIO connected to the data line.
|
||||
- "clk-gpios": GPIO connected to the clock line.
|
||||
- "vcc-supply": regulator that drives the VCC pin.
|
||||
|
||||
Example:
|
||||
|
||||
sensor {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_sensor>;
|
||||
compatible = "sensirion,sht15";
|
||||
clk-gpios = <&gpio4 12 0>;
|
||||
data-gpios = <&gpio4 13 0>;
|
||||
vcc-supply = <®_sht15>;
|
||||
};
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/ti,tmp102.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TMP102 temperature sensor
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ti,tmp102
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#thermal-sensor-cells":
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
sensor@48 {
|
||||
compatible = "ti,tmp102";
|
||||
reg = <0x48>;
|
||||
interrupt-parent = <&gpio7>;
|
||||
interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
|
||||
#thermal-sensor-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/ti,tmp108.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TMP108 temperature sensor
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ti,tmp108
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: alert interrupt
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#thermal-sensor-cells":
|
||||
const: 0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
sensor@48 {
|
||||
compatible = "ti,tmp108";
|
||||
reg = <0x48>;
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&tmp_alrt>;
|
||||
#thermal-sensor-cells = <0>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,110 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/ti,tmp421.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TMP42x/TMP44x temperature sensor
|
||||
|
||||
maintainers:
|
||||
- Guenter Roeck <linux@roeck-us.net>
|
||||
|
||||
description: |
|
||||
±1°C Remote and Local temperature sensor
|
||||
https://www.ti.com/lit/ds/symlink/tmp422.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ti,tmp421
|
||||
- ti,tmp422
|
||||
- ti,tmp423
|
||||
- ti,tmp441
|
||||
- ti,tmp442
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
patternProperties:
|
||||
"^channel@([0-3])$":
|
||||
type: object
|
||||
description: |
|
||||
Represents channels of the device and their specific configuration.
|
||||
|
||||
properties:
|
||||
reg:
|
||||
description: |
|
||||
The channel number. 0 is local channel, 1-3 are remote channels
|
||||
items:
|
||||
minimum: 0
|
||||
maximum: 3
|
||||
|
||||
label:
|
||||
description: |
|
||||
A descriptive name for this channel, like "ambient" or "psu".
|
||||
|
||||
ti,n-factor:
|
||||
description: |
|
||||
The value (two's complement) to be programmed in the channel specific N correction register.
|
||||
For remote channels only.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
items:
|
||||
minimum: 0
|
||||
maximum: 255
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
sensor@4c {
|
||||
compatible = "ti,tmp422";
|
||||
reg = <0x4c>;
|
||||
};
|
||||
};
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
sensor@4c {
|
||||
compatible = "ti,tmp422";
|
||||
reg = <0x4c>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
channel@0 {
|
||||
reg = <0x0>;
|
||||
ti,n-factor = <0x1>;
|
||||
label = "local";
|
||||
};
|
||||
|
||||
channel@1 {
|
||||
reg = <0x1>;
|
||||
ti,n-factor = <0x0>;
|
||||
label = "somelabel";
|
||||
};
|
||||
|
||||
channel@2 {
|
||||
reg = <0x2>;
|
||||
status = "disabled";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
TMP108 temperature sensor
|
||||
-------------------------
|
||||
|
||||
This device supports I2C only.
|
||||
|
||||
Requires node properties:
|
||||
- compatible : "ti,tmp108"
|
||||
- reg : the I2C address of the device. This is 0x48, 0x49, 0x4a, or 0x4b.
|
||||
|
||||
Optional properties:
|
||||
- interrupts: Reference to the TMP108 alert interrupt.
|
||||
- #thermal-sensor-cells: should be set to 0.
|
||||
|
||||
Example:
|
||||
tmp108@48 {
|
||||
compatible = "ti,tmp108";
|
||||
reg = <0x48>;
|
||||
};
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interrupt-controller/microchip,eic.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Microchip External Interrupt Controller
|
||||
|
||||
maintainers:
|
||||
- Claudiu Beznea <claudiu.beznea@microchip.com>
|
||||
|
||||
description:
|
||||
This interrupt controller is found in Microchip SoCs (SAMA7G5) and provides
|
||||
support for handling up to 2 external interrupt lines.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- microchip,sama7g5-eic
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
'#interrupt-cells':
|
||||
const: 2
|
||||
description:
|
||||
The first cell is the input IRQ number (between 0 and 1), the second cell
|
||||
is the trigger type as defined in interrupt.txt present in this directory.
|
||||
|
||||
interrupts:
|
||||
description: |
|
||||
Contains the GIC SPI IRQs mapped to the external interrupt lines. They
|
||||
should be specified sequentially from output 0 to output 1.
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
const: pclk
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupt-controller
|
||||
- '#interrupt-cells'
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/at91.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
eic: interrupt-controller@e1628000 {
|
||||
compatible = "microchip,sama7g5-eic";
|
||||
reg = <0xe1628000 0x100>;
|
||||
interrupt-parent = <&gic>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&pmc PMC_TYPE_PERIPHERAL 37>;
|
||||
clock-names = "pclk";
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -27,6 +27,7 @@ properties:
|
|||
- renesas,intc-ex-r8a774a1 # RZ/G2M
|
||||
- renesas,intc-ex-r8a774b1 # RZ/G2N
|
||||
- renesas,intc-ex-r8a774c0 # RZ/G2E
|
||||
- renesas,intc-ex-r8a774e1 # RZ/G2H
|
||||
- renesas,intc-ex-r8a7795 # R-Car H3
|
||||
- renesas,intc-ex-r8a7796 # R-Car M3-W
|
||||
- renesas,intc-ex-r8a77961 # R-Car M3-W+
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ Required properties:
|
|||
- compatible : should be one of
|
||||
"aspeed,ast2400-ibt-bmc"
|
||||
"aspeed,ast2500-ibt-bmc"
|
||||
"aspeed,ast2600-ibt-bmc"
|
||||
- reg: physical address and size of the registers
|
||||
|
||||
Optional properties:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,59 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/ipmi/ipmi-ipmb.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: IPMI IPMB device bindings
|
||||
|
||||
description: IPMI IPMB device bindings
|
||||
|
||||
maintainers:
|
||||
- Corey Minyard <cminyard@mvista.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ipmi-ipmb
|
||||
|
||||
device_type:
|
||||
items:
|
||||
- const: "ipmi"
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
bmcaddr:
|
||||
$ref: /schemas/types.yaml#/definitions/uint8
|
||||
description: The address of the BMC on the IPMB bus. Defaults to 0x20.
|
||||
|
||||
retry-time:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Time between retries of sends, in milliseconds. Defaults to 250.
|
||||
|
||||
max-retries:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: Number of retries before a failure is declared. Defaults to 1.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ipmi-ipmb@40 {
|
||||
compatible = "ipmi-ipmb";
|
||||
device_type = "ipmi";
|
||||
reg = <0x40>;
|
||||
bmcaddr = /bits/ 8 <0x20>;
|
||||
retry-time = <250>;
|
||||
max-retries = <1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/mailbox/apple,mailbox.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Apple Mailbox Controller
|
||||
|
||||
maintainers:
|
||||
- Hector Martin <marcan@marcan.st>
|
||||
- Sven Peter <sven@svenpeter.dev>
|
||||
|
||||
description:
|
||||
The Apple mailbox consists of two FIFOs used to exchange 64+32 bit
|
||||
messages between the main CPU and a co-processor. Multiple instances
|
||||
of this mailbox can be found on Apple SoCs.
|
||||
One of the two FIFOs is used to send data to a co-processor while the other
|
||||
FIFO is used for the other direction.
|
||||
Various clients implement different IPC protocols based on these simple
|
||||
messages and shared memory buffers.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- description:
|
||||
ASC mailboxes are the most common variant found on the M1 used
|
||||
for example for the display controller, the system management
|
||||
controller and the NVMe coprocessor.
|
||||
items:
|
||||
- const: apple,t8103-asc-mailbox
|
||||
|
||||
- description:
|
||||
M3 mailboxes are an older variant with a slightly different MMIO
|
||||
interface still found on the M1. It is used for the Thunderbolt
|
||||
co-processors.
|
||||
items:
|
||||
- const: apple,t8103-m3-mailbox
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: send fifo is empty interrupt
|
||||
- description: send fifo is not empty interrupt
|
||||
- description: receive fifo is empty interrupt
|
||||
- description: receive fifo is not empty interrupt
|
||||
|
||||
interrupt-names:
|
||||
items:
|
||||
- const: send-empty
|
||||
- const: send-not-empty
|
||||
- const: recv-empty
|
||||
- const: recv-not-empty
|
||||
|
||||
"#mbox-cells":
|
||||
const: 0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- interrupt-names
|
||||
- "#mbox-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
mailbox@77408000 {
|
||||
compatible = "apple,t8103-asc-mailbox";
|
||||
reg = <0x77408000 0x4000>;
|
||||
interrupts = <1 583 4>, <1 584 4>, <1 585 4>, <1 586 4>;
|
||||
interrupt-names = "send-empty", "send-not-empty",
|
||||
"recv-empty", "recv-not-empty";
|
||||
#mbox-cells = <0>;
|
||||
};
|
||||
|
|
@ -28,6 +28,7 @@ properties:
|
|||
- const: fsl,imx7ulp-mu
|
||||
- const: fsl,imx8ulp-mu
|
||||
- const: fsl,imx8-mu-scu
|
||||
- const: fsl,imx8ulp-mu-s4
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx7s-mu
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ description:
|
|||
platforms.
|
||||
|
||||
maintainers:
|
||||
- Sivaprakash Murugesan <sivaprak@codeaurora.org>
|
||||
- Jassi Brar <jassisinghbrar@gmail.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
@ -24,6 +24,7 @@ properties:
|
|||
- qcom,msm8994-apcs-kpss-global
|
||||
- qcom,msm8996-apcs-hmss-global
|
||||
- qcom,msm8998-apcs-hmss-global
|
||||
- qcom,qcm2290-apcs-hmss-global
|
||||
- qcom,qcs404-apcs-apps-global
|
||||
- qcom,sc7180-apss-shared
|
||||
- qcom,sc8180x-apss-shared
|
||||
|
|
|
|||
|
|
@ -4,23 +4,24 @@
|
|||
$id: http://devicetree.org/schemas/media/i2c/adv7604.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Analog Devices ADV7604/11/12 video decoder with HDMI receiver
|
||||
title: Analog Devices ADV7604/10/11/12 video decoder with HDMI receiver
|
||||
|
||||
maintainers:
|
||||
- Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
||||
|
||||
description:
|
||||
The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated
|
||||
HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog
|
||||
input, and the ADV7611 has one HDMI input and no analog input. The 7612 is
|
||||
similar to the 7611 but has 2 HDMI inputs.
|
||||
The ADV7604 and ADV7610/11/12 are multiformat video decoders with
|
||||
an integrated HDMI receiver. The ADV7604 has four multiplexed HDMI inputs
|
||||
and one analog input, and the ADV7610/11 have one HDMI input and no analog
|
||||
input. The ADV7612 is similar to the ADV7610/11 but has 2 HDMI inputs.
|
||||
|
||||
These device tree bindings support the ADV7611/12 only at the moment.
|
||||
These device tree bindings support the ADV7610/11/12 only at the moment.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- adi,adv7610
|
||||
- adi,adv7611
|
||||
- adi,adv7612
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,108 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/aptina,mt9p031.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor
|
||||
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
|
||||
description: |
|
||||
The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor
|
||||
with an active array size of 2592H x 1944V. It is programmable through a
|
||||
simple two-wire serial interface.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- aptina,mt9p031
|
||||
- aptina,mt9p031m
|
||||
|
||||
reg:
|
||||
description: I2C device address
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
vdd-supply:
|
||||
description: Digital supply voltage, 1.8 V
|
||||
|
||||
vdd_io-supply:
|
||||
description: I/O supply voltage, 1.8 or 2.8 V
|
||||
|
||||
vaa-supply:
|
||||
description: Analog supply voltage, 2.8 V
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
description: Chip reset GPIO
|
||||
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
input-clock-frequency:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 6000000
|
||||
maximum: 96000000
|
||||
description: Input clock frequency
|
||||
|
||||
pixel-clock-frequency:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
maximum: 96000000
|
||||
description: Target pixel clock frequency
|
||||
|
||||
pclk-sample:
|
||||
default: 0
|
||||
|
||||
required:
|
||||
- input-clock-frequency
|
||||
- pixel-clock-frequency
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- vdd-supply
|
||||
- vdd_io-supply
|
||||
- vaa-supply
|
||||
- port
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
mt9p031@5d {
|
||||
compatible = "aptina,mt9p031";
|
||||
reg = <0x5d>;
|
||||
reset-gpios = <&gpio_sensor 0 0>;
|
||||
|
||||
clocks = <&sensor_clk>;
|
||||
|
||||
vdd-supply = <®_vdd>;
|
||||
vdd_io-supply = <®_vdd_io>;
|
||||
vaa-supply = <®_vaa>;
|
||||
|
||||
port {
|
||||
mt9p031_1: endpoint {
|
||||
input-clock-frequency = <6000000>;
|
||||
pixel-clock-frequency = <96000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,120 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/hynix,hi846.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: SK Hynix Hi-846 1/4" 8M Pixel MIPI CSI-2 sensor
|
||||
|
||||
maintainers:
|
||||
- Martin Kepplinger <martin.kepplinger@puri.sm>
|
||||
|
||||
description: |-
|
||||
The Hi-846 is a raw image sensor with an MIPI CSI-2 image data
|
||||
interface and CCI (I2C compatible) control bus. The output format
|
||||
is raw Bayer.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: hynix,hi846
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Reference to the mclk clock.
|
||||
|
||||
assigned-clocks:
|
||||
maxItems: 1
|
||||
|
||||
assigned-clock-rates:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
description: Reference to the GPIO connected to the RESETB pin. Active low.
|
||||
maxItems: 1
|
||||
|
||||
shutdown-gpios:
|
||||
description: Reference to the GPIO connected to the XSHUTDOWN pin. Active low.
|
||||
maxItems: 1
|
||||
|
||||
vddio-supply:
|
||||
description: Definition of the regulator used for the VDDIO power supply.
|
||||
|
||||
vdda-supply:
|
||||
description: Definition of the regulator used for the VDDA power supply.
|
||||
|
||||
vddd-supply:
|
||||
description: Definition of the regulator used for the VDDD power supply.
|
||||
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
data-lanes:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
- const: 3
|
||||
- const: 4
|
||||
- items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
|
||||
required:
|
||||
- data-lanes
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- assigned-clocks
|
||||
- assigned-clock-rates
|
||||
- vddio-supply
|
||||
- vdda-supply
|
||||
- vddd-supply
|
||||
- port
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
hi846: camera@20 {
|
||||
compatible = "hynix,hi846";
|
||||
reg = <0x20>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_csi1>;
|
||||
clocks = <&clk 0>;
|
||||
assigned-clocks = <&clk 0>;
|
||||
assigned-clock-rates = <25000000>;
|
||||
vdda-supply = <®_camera_vdda>;
|
||||
vddd-supply = <®_camera_vddd>;
|
||||
vddio-supply = <®_camera_vddio>;
|
||||
reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
|
||||
shutdown-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
|
||||
|
||||
port {
|
||||
camera_out: endpoint {
|
||||
remote-endpoint = <&csi1_ep1>;
|
||||
link-frequencies = /bits/ 64
|
||||
<80000000 200000000>;
|
||||
data-lanes = <1 2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor
|
||||
|
||||
The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor with
|
||||
an active array size of 2592H x 1944V. It is programmable through a simple
|
||||
two-wire serial interface.
|
||||
|
||||
Required Properties:
|
||||
- compatible: value should be either one among the following
|
||||
(a) "aptina,mt9p031" for mt9p031 sensor
|
||||
(b) "aptina,mt9p031m" for mt9p031m sensor
|
||||
|
||||
- input-clock-frequency: Input clock frequency.
|
||||
|
||||
- pixel-clock-frequency: Pixel clock frequency.
|
||||
|
||||
Optional Properties:
|
||||
- reset-gpios: Chip reset GPIO
|
||||
|
||||
For further reading on port node refer to
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
Example:
|
||||
|
||||
i2c0@1c22000 {
|
||||
...
|
||||
...
|
||||
mt9p031@5d {
|
||||
compatible = "aptina,mt9p031";
|
||||
reg = <0x5d>;
|
||||
reset-gpios = <&gpio3 30 0>;
|
||||
|
||||
port {
|
||||
mt9p031_1: endpoint {
|
||||
input-clock-frequency = <6000000>;
|
||||
pixel-clock-frequency = <96000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
};
|
||||
|
|
@ -10,6 +10,8 @@ Required properties:
|
|||
"mediatek,mt8183-vcodec-enc" for MT8183 encoder.
|
||||
"mediatek,mt8173-vcodec-dec" for MT8173 decoder.
|
||||
"mediatek,mt8192-vcodec-enc" for MT8192 encoder.
|
||||
"mediatek,mt8183-vcodec-dec" for MT8183 decoder.
|
||||
"mediatek,mt8195-vcodec-enc" for MT8195 encoder.
|
||||
- reg : Physical base address of the video codec registers and length of
|
||||
memory mapped region.
|
||||
- interrupts : interrupt number to the cpu.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,162 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/media/qcom,sc7280-venus.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Qualcomm Venus video encode and decode accelerators
|
||||
|
||||
maintainers:
|
||||
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
|
||||
|
||||
description: |
|
||||
The Venus Iris2 IP is a video encode and decode accelerator present
|
||||
on Qualcomm platforms
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sc7280-venus
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
power-domains:
|
||||
minItems: 2
|
||||
maxItems: 3
|
||||
|
||||
power-domain-names:
|
||||
minItems: 2
|
||||
maxItems: 3
|
||||
items:
|
||||
- const: venus
|
||||
- const: vcodec0
|
||||
- const: cx
|
||||
|
||||
clocks:
|
||||
maxItems: 5
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: core
|
||||
- const: bus
|
||||
- const: iface
|
||||
- const: vcodec_core
|
||||
- const: vcodec_bus
|
||||
|
||||
iommus:
|
||||
maxItems: 2
|
||||
|
||||
memory-region:
|
||||
maxItems: 1
|
||||
|
||||
interconnects:
|
||||
maxItems: 2
|
||||
|
||||
interconnect-names:
|
||||
items:
|
||||
- const: cpu-cfg
|
||||
- const: video-mem
|
||||
|
||||
video-decoder:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: venus-decoder
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
video-encoder:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: venus-encoder
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
video-firmware:
|
||||
type: object
|
||||
|
||||
description: |
|
||||
Firmware subnode is needed when the platform does not
|
||||
have TrustZone.
|
||||
|
||||
properties:
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- iommus
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- power-domains
|
||||
- power-domain-names
|
||||
- clocks
|
||||
- clock-names
|
||||
- iommus
|
||||
- memory-region
|
||||
- video-decoder
|
||||
- video-encoder
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/clock/qcom,videocc-sc7280.h>
|
||||
#include <dt-bindings/interconnect/qcom,sc7280.h>
|
||||
#include <dt-bindings/power/qcom-rpmpd.h>
|
||||
|
||||
venus: video-codec@aa00000 {
|
||||
compatible = "qcom,sc7280-venus";
|
||||
reg = <0x0aa00000 0xd0600>;
|
||||
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
clocks = <&videocc VIDEO_CC_MVSC_CORE_CLK>,
|
||||
<&videocc VIDEO_CC_MVSC_CTL_AXI_CLK>,
|
||||
<&videocc VIDEO_CC_VENUS_AHB_CLK>,
|
||||
<&videocc VIDEO_CC_MVS0_CORE_CLK>,
|
||||
<&videocc VIDEO_CC_MVS0_AXI_CLK>;
|
||||
clock-names = "core", "bus", "iface",
|
||||
"vcodec_core", "vcodec_bus";
|
||||
|
||||
power-domains = <&videocc MVSC_GDSC>,
|
||||
<&videocc MVS0_GDSC>,
|
||||
<&rpmhpd SC7280_CX>;
|
||||
power-domain-names = "venus", "vcodec0", "cx";
|
||||
|
||||
interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>,
|
||||
<&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>;
|
||||
interconnect-names = "cpu-cfg", "video-mem";
|
||||
|
||||
iommus = <&apps_smmu 0x2180 0x20>,
|
||||
<&apps_smmu 0x2184 0x20>;
|
||||
|
||||
memory-region = <&video_mem>;
|
||||
|
||||
video-decoder {
|
||||
compatible = "venus-decoder";
|
||||
};
|
||||
|
||||
video-encoder {
|
||||
compatible = "venus-encoder";
|
||||
};
|
||||
|
||||
video-firmware {
|
||||
iommus = <&apps_smmu 0x21a2 0x0>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,186 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/media/qcom,sdm660-venus.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Qualcomm Venus video encode and decode accelerators
|
||||
|
||||
maintainers:
|
||||
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
|
||||
- AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
||||
|
||||
description: |
|
||||
The Venus IP is a video encode and decode accelerator present
|
||||
on Qualcomm platforms
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sdm660-venus
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 4
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: core
|
||||
- const: iface
|
||||
- const: bus
|
||||
- const: bus_throttle
|
||||
|
||||
interconnects:
|
||||
maxItems: 2
|
||||
|
||||
interconnect-names:
|
||||
items:
|
||||
- const: cpu-cfg
|
||||
- const: video-mem
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
iommus:
|
||||
maxItems: 20
|
||||
|
||||
memory-region:
|
||||
maxItems: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
video-decoder:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: venus-decoder
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: vcodec0_core
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- clock-names
|
||||
- power-domains
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
video-encoder:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: venus-encoder
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: vcodec0_core
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- clock-names
|
||||
- power-domains
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
video-firmware:
|
||||
type: object
|
||||
|
||||
description: |
|
||||
Firmware subnode is needed when the platform does not
|
||||
have TrustZone.
|
||||
|
||||
properties:
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- iommus
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
- interrupts
|
||||
- iommus
|
||||
- memory-region
|
||||
- power-domains
|
||||
- video-decoder
|
||||
- video-encoder
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,mmcc-sdm660.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
video-codec@cc00000 {
|
||||
compatible = "qcom,sdm660-venus";
|
||||
reg = <0x0cc00000 0xff000>;
|
||||
clocks = <&mmcc VIDEO_CORE_CLK>,
|
||||
<&mmcc VIDEO_AHB_CLK>,
|
||||
<&mmcc VIDEO_AXI_CLK>,
|
||||
<&mmcc THROTTLE_VIDEO_AXI_CLK>;
|
||||
clock-names = "core", "iface", "bus", "bus_throttle";
|
||||
interconnects = <&gnoc 0 &mnoc 13>,
|
||||
<&mnoc 4 &bimc 5>;
|
||||
interconnect-names = "cpu-cfg", "video-mem";
|
||||
interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
|
||||
iommus = <&mmss_smmu 0x400>,
|
||||
<&mmss_smmu 0x401>,
|
||||
<&mmss_smmu 0x40a>,
|
||||
<&mmss_smmu 0x407>,
|
||||
<&mmss_smmu 0x40e>,
|
||||
<&mmss_smmu 0x40f>,
|
||||
<&mmss_smmu 0x408>,
|
||||
<&mmss_smmu 0x409>,
|
||||
<&mmss_smmu 0x40b>,
|
||||
<&mmss_smmu 0x40c>,
|
||||
<&mmss_smmu 0x40d>,
|
||||
<&mmss_smmu 0x410>,
|
||||
<&mmss_smmu 0x421>,
|
||||
<&mmss_smmu 0x428>,
|
||||
<&mmss_smmu 0x429>,
|
||||
<&mmss_smmu 0x42b>,
|
||||
<&mmss_smmu 0x42c>,
|
||||
<&mmss_smmu 0x42d>,
|
||||
<&mmss_smmu 0x411>,
|
||||
<&mmss_smmu 0x431>;
|
||||
memory-region = <&venus_region>;
|
||||
power-domains = <&mmcc VENUS_GDSC>;
|
||||
|
||||
video-decoder {
|
||||
compatible = "venus-decoder";
|
||||
clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
|
||||
clock-names = "vcodec0_core";
|
||||
power-domains = <&mmcc VENUS_CORE0_GDSC>;
|
||||
};
|
||||
|
||||
video-encoder {
|
||||
compatible = "venus-encoder";
|
||||
clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
|
||||
clock-names = "vcodec0_core";
|
||||
power-domains = <&mmcc VENUS_CORE0_GDSC>;
|
||||
};
|
||||
};
|
||||
|
|
@ -30,6 +30,7 @@ properties:
|
|||
- renesas,r8a77970-csi2 # R-Car V3M
|
||||
- renesas,r8a77980-csi2 # R-Car V3H
|
||||
- renesas,r8a77990-csi2 # R-Car E3
|
||||
- renesas,r8a779a0-csi2 # R-Car V3U
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -1,31 +0,0 @@
|
|||
Renesas R-Car Image Renderer (Distortion Correction Engine)
|
||||
-----------------------------------------------------------
|
||||
|
||||
The image renderer, or the distortion correction engine, is a drawing processor
|
||||
with a simple instruction system capable of referencing video capture data or
|
||||
data in an external memory as 2D texture data and performing texture mapping
|
||||
and drawing with respect to any shape that is split into triangular objects.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "renesas,<soctype>-imr-lx4", "renesas,imr-lx4" as a fallback for
|
||||
the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
|
||||
where the examples with <soctype> are:
|
||||
- "renesas,r8a7795-imr-lx4" for R-Car H3,
|
||||
- "renesas,r8a7796-imr-lx4" for R-Car M3-W.
|
||||
- reg: offset and length of the register block;
|
||||
- interrupts: single interrupt specifier;
|
||||
- clocks: single clock phandle/specifier pair;
|
||||
- power-domains: power domain phandle/specifier pair;
|
||||
- resets: reset phandle/specifier pair.
|
||||
|
||||
Example:
|
||||
|
||||
imr-lx4@fe860000 {
|
||||
compatible = "renesas,r8a7795-imr-lx4", "renesas,imr-lx4";
|
||||
reg = <0 0xfe860000 0 0x2000>;
|
||||
interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cpg CPG_MOD 823>;
|
||||
power-domains = <&sysc R8A7795_PD_A3VC>;
|
||||
resets = <&cpg 823>;
|
||||
};
|
||||
|
|
@ -0,0 +1,67 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/renesas,imr.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas R-Car Image Renderer (Distortion Correction Engine)
|
||||
|
||||
maintainers:
|
||||
- Sergei Shtylyov <sergei.shtylyov@gmail.com>
|
||||
|
||||
description: |
|
||||
The image renderer, or the distortion correction engine, is a drawing
|
||||
processor with a simple instruction system capable of referencing video
|
||||
capture data or data in an external memory as 2D texture data and performing
|
||||
texture mapping and drawing with respect to any shape that is split into
|
||||
triangular objects.
|
||||
|
||||
The image renderer light extended 4 (IMR-LX4) is found in R-Car Gen3 SoCs.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- renesas,r8a7795-imr-lx4 # R-Car H3
|
||||
- renesas,r8a7796-imr-lx4 # R-Car M3-W
|
||||
- const: renesas,imr-lx4 # R-Car Gen3
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- power-domains
|
||||
- resets
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/r8a7795-cpg-mssr.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/power/r8a7795-sysc.h>
|
||||
|
||||
imr-lx4@fe860000 {
|
||||
compatible = "renesas,r8a7795-imr-lx4", "renesas,imr-lx4";
|
||||
reg = <0xfe860000 0x2000>;
|
||||
interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cpg CPG_MOD 823>;
|
||||
power-domains = <&sysc R8A7795_PD_A3VC>;
|
||||
resets = <&cpg 823>;
|
||||
};
|
||||
|
|
@ -15,13 +15,22 @@ description: |
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
const: rockchip,rk3399-cif-isp
|
||||
enum:
|
||||
- rockchip,px30-cif-isp
|
||||
- rockchip,rk3399-cif-isp
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
|
||||
interrupt-names:
|
||||
items:
|
||||
- const: isp
|
||||
- const: mi
|
||||
- const: mipi
|
||||
|
||||
clocks:
|
||||
minItems: 3
|
||||
|
|
@ -41,7 +50,7 @@ properties:
|
|||
- const: aclk
|
||||
- const: hclk
|
||||
# only for isp1
|
||||
- const: pclk_isp
|
||||
- const: pclk
|
||||
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
|
@ -90,19 +99,29 @@ required:
|
|||
- power-domains
|
||||
- ports
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: rockchip,rk3399-cif-isp
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
minItems: 3
|
||||
maxItems: 4
|
||||
clock-names:
|
||||
minItems: 3
|
||||
maxItems: 4
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: rockchip,rk3399-cif-isp
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
minItems: 3
|
||||
maxItems: 4
|
||||
clock-names:
|
||||
minItems: 3
|
||||
maxItems: 4
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: rockchip,px30-cif-isp
|
||||
then:
|
||||
required:
|
||||
- interrupt-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
@ -183,3 +202,66 @@ examples:
|
|||
};
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/power/px30-power.h>
|
||||
|
||||
parent1: parent {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
|
||||
isp: isp@ff4a0000 {
|
||||
compatible = "rockchip,px30-cif-isp";
|
||||
reg = <0x0 0xff4a0000 0x0 0x8000>;
|
||||
interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "isp", "mi", "mipi";
|
||||
clocks = <&cru SCLK_ISP0>,
|
||||
<&cru ACLK_ISP0_WRAPPER>,
|
||||
<&cru HCLK_ISP0_WRAPPER>,
|
||||
<&cru PCLK_ISP1_WRAPPER>;
|
||||
clock-names = "isp", "aclk", "hclk", "pclk";
|
||||
iommus = <&isp_mmu>;
|
||||
phys = <&csi_dphy>;
|
||||
phy-names = "dphy";
|
||||
power-domains = <&power PX30_PD_VI>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
mipi_in_ucam1: endpoint@0 {
|
||||
reg = <0>;
|
||||
remote-endpoint = <&ucam1_out>;
|
||||
data-lanes = <1 2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
i2c2: i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ov5695: camera@36 {
|
||||
compatible = "ovti,ov5647";
|
||||
reg = <0x36>;
|
||||
clocks = <&cru SCLK_CIF_OUT>;
|
||||
|
||||
port {
|
||||
ucam1_out: endpoint {
|
||||
remote-endpoint = <&mipi_in_ucam1>;
|
||||
data-lanes = <1 2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -88,6 +88,12 @@ properties:
|
|||
description:
|
||||
For this device it is strongly suggested to include
|
||||
arasan,soc-ctl-syscon.
|
||||
- items:
|
||||
- const: intel,thunderbay-sdhci-5.1 # Intel Thunder Bay eMMC PHY
|
||||
- const: arasan,sdhci-5.1
|
||||
description:
|
||||
For this device it is strongly suggested to include
|
||||
clock-output-names and '#clock-cells'.
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
@ -153,7 +159,6 @@ properties:
|
|||
The MIO bank number in which the command and data lines are configured.
|
||||
|
||||
dependencies:
|
||||
clock-output-names: [ '#clock-cells' ]
|
||||
'#clock-cells': [ clock-output-names ]
|
||||
|
||||
required:
|
||||
|
|
@ -301,3 +306,22 @@ examples:
|
|||
<&scmi_clk KEEM_BAY_PSS_SD0>;
|
||||
arasan,soc-ctl-syscon = <&sd0_phy_syscon>;
|
||||
};
|
||||
|
||||
- |
|
||||
#define EMMC_XIN_CLK
|
||||
#define EMMC_AXI_CLK
|
||||
#define TBH_PSS_EMMC_RST_N
|
||||
mmc@80420000 {
|
||||
compatible = "intel,thunderbay-sdhci-5.1", "arasan,sdhci-5.1";
|
||||
interrupts = <GIC_SPI 714 IRQ_TYPE_LEVEL_HIGH>;
|
||||
reg = <0x80420000 0x400>;
|
||||
clocks = <&scmi_clk EMMC_XIN_CLK>,
|
||||
<&scmi_clk EMMC_AXI_CLK>;
|
||||
clock-names = "clk_xin", "clk_ahb";
|
||||
phys = <&emmc_phy>;
|
||||
phy-names = "phy_arasan";
|
||||
assigned-clocks = <&scmi_clk EMMC_XIN_CLK>;
|
||||
clock-output-names = "emmc_cardclock";
|
||||
resets = <&rst_pss1 TBH_PSS_EMMC_RST_N>;
|
||||
#clock-cells = <0x0>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -17,6 +17,7 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- microchip,mpfs-sd4hc
|
||||
- socionext,uniphier-sd4hc
|
||||
- const: cdns,sd4hc
|
||||
|
||||
|
|
|
|||
|
|
@ -34,6 +34,7 @@ properties:
|
|||
- fsl,imx6ull-usdhc
|
||||
- fsl,imx7d-usdhc
|
||||
- fsl,imx7ulp-usdhc
|
||||
- nxp,s32g2-usdhc
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx8mm-usdhc
|
||||
|
|
|
|||
|
|
@ -1,30 +0,0 @@
|
|||
mmc-card / eMMC bindings
|
||||
------------------------
|
||||
|
||||
This documents describes the devicetree bindings for a mmc-host controller
|
||||
child node describing a mmc-card / an eMMC, see "Use of Function subnodes"
|
||||
in mmc.txt
|
||||
|
||||
Required properties:
|
||||
-compatible : Must be "mmc-card"
|
||||
-reg : Must be <0>
|
||||
|
||||
Optional properties:
|
||||
-broken-hpi : Use this to indicate that the mmc-card has a broken hpi
|
||||
implementation, and that hpi should not be used
|
||||
|
||||
Example:
|
||||
|
||||
&mmc2 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc2_pins_a>;
|
||||
vmmc-supply = <®_vcc3v3>;
|
||||
bus-width = <8>;
|
||||
non-removable;
|
||||
|
||||
mmccard: mmccard@0 {
|
||||
reg = <0>;
|
||||
compatible = "mmc-card";
|
||||
broken-hpi;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/mmc/mmc-card.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MMC Card / eMMC Generic Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Ulf Hansson <ulf.hansson@linaro.org>
|
||||
|
||||
description: |
|
||||
This documents describes the devicetree bindings for a mmc-host controller
|
||||
child node describing a mmc-card / an eMMC.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: mmc-card
|
||||
|
||||
reg:
|
||||
const: 0
|
||||
|
||||
broken-hpi:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Use this to indicate that the mmc-card has a broken hpi
|
||||
implementation, and that hpi should not be used.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
mmc {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
card@0 {
|
||||
compatible = "mmc-card";
|
||||
reg = <0>;
|
||||
broken-hpi;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -333,12 +333,6 @@ patternProperties:
|
|||
subnode describes. A value of 0 denotes the memory SD
|
||||
function, values from 1 to 7 denote the SDIO functions.
|
||||
|
||||
broken-hpi:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Use this to indicate that the mmc-card has a broken hpi
|
||||
implementation, and that hpi should not be used.
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
|
|
|
|||
|
|
@ -119,6 +119,18 @@ properties:
|
|||
If present, HS400 command responses are sampled on rising edges.
|
||||
If not present, HS400 command responses are sampled on falling edges.
|
||||
|
||||
mediatek,hs400-ds-dly3:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Gear of the third delay line for DS for input data latch in data
|
||||
pad macro, there are 32 stages from 0 to 31.
|
||||
For different corner IC, the time is different about one step, it is
|
||||
about 100ps.
|
||||
The value is confirmed by doing scan and calibration to find a best
|
||||
value with corner IC and it is valid only for HS400 mode.
|
||||
minimum: 0
|
||||
maximum: 31
|
||||
|
||||
mediatek,latch-ck:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
|
|
|
|||
|
|
@ -13,6 +13,7 @@ Required properties:
|
|||
string is added to support this change - "qcom,sdhci-msm-v5".
|
||||
full compatible strings with SoC and version:
|
||||
"qcom,apq8084-sdhci", "qcom,sdhci-msm-v4"
|
||||
"qcom,msm8226-sdhci", "qcom,sdhci-msm-v4"
|
||||
"qcom,msm8974-sdhci", "qcom,sdhci-msm-v4"
|
||||
"qcom,msm8916-sdhci", "qcom,sdhci-msm-v4"
|
||||
"qcom,msm8992-sdhci", "qcom,sdhci-msm-v4"
|
||||
|
|
|
|||
|
|
@ -5,7 +5,11 @@ Refer to mmc.txt for standard MMC bindings.
|
|||
For UHS devices which require tuning, the device tree should have a "cpu_thermal" node which maps to the appropriate thermal zone. This is used to get the temperature of the zone during tuning.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "ti,dra7-sdhci" for DRA7 and DRA72 controllers
|
||||
- compatible: Should be "ti,omap2430-sdhci" for omap2430 controllers
|
||||
Should be "ti,omap3-sdhci" for omap3 controllers
|
||||
Should be "ti,omap4-sdhci" for omap4 and ti81 controllers
|
||||
Should be "ti,omap5-sdhci" for omap5 controllers
|
||||
Should be "ti,dra7-sdhci" for DRA7 and DRA72 controllers
|
||||
Should be "ti,k2g-sdhci" for K2G
|
||||
Should be "ti,am335-sdhci" for am335x controllers
|
||||
Should be "ti,am437-sdhci" for am437x controllers
|
||||
|
|
@ -24,6 +28,9 @@ Optional properties:
|
|||
DMA specifiers listed in dmas. The string naming is to be "tx"
|
||||
and "rx" for TX and RX DMA requests, respectively.
|
||||
|
||||
Deprecated properties:
|
||||
- ti,non-removable: Compatible with the generic non-removable property
|
||||
|
||||
Example:
|
||||
mmc1: mmc@4809c000 {
|
||||
compatible = "ti,dra7-sdhci";
|
||||
|
|
|
|||
|
|
@ -1,52 +0,0 @@
|
|||
Maxim MAX8952 voltage regulator
|
||||
|
||||
Required properties:
|
||||
- compatible: must be equal to "maxim,max8952"
|
||||
- reg: I2C slave address, usually 0x60
|
||||
- max8952,dvs-mode-microvolt: array of 4 integer values defining DVS voltages
|
||||
in microvolts. All values must be from range <770000, 1400000>
|
||||
- any required generic properties defined in regulator.txt
|
||||
|
||||
Optional properties:
|
||||
- max8952,vid-gpios: array of two GPIO pins used for DVS voltage selection
|
||||
- max8952,en-gpio: GPIO used to control enable status of regulator
|
||||
- max8952,default-mode: index of default DVS voltage, from <0, 3> range
|
||||
- max8952,sync-freq: sync frequency, must be one of following values:
|
||||
- 0: 26 MHz
|
||||
- 1: 13 MHz
|
||||
- 2: 19.2 MHz
|
||||
Defaults to 26 MHz if not specified.
|
||||
- max8952,ramp-speed: voltage ramp speed, must be one of following values:
|
||||
- 0: 32mV/us
|
||||
- 1: 16mV/us
|
||||
- 2: 8mV/us
|
||||
- 3: 4mV/us
|
||||
- 4: 2mV/us
|
||||
- 5: 1mV/us
|
||||
- 6: 0.5mV/us
|
||||
- 7: 0.25mV/us
|
||||
Defaults to 32mV/us if not specified.
|
||||
- any available generic properties defined in regulator.txt
|
||||
|
||||
Example:
|
||||
|
||||
vdd_arm_reg: pmic@60 {
|
||||
compatible = "maxim,max8952";
|
||||
reg = <0x60>;
|
||||
|
||||
/* max8952-specific properties */
|
||||
max8952,vid-gpios = <&gpx0 3 0>, <&gpx0 4 0>;
|
||||
max8952,en-gpio = <&gpx0 1 0>;
|
||||
max8952,default-mode = <0>;
|
||||
max8952,dvs-mode-microvolt = <1250000>, <1200000>,
|
||||
<1050000>, <950000>;
|
||||
max8952,sync-freq = <0>;
|
||||
max8952,ramp-speed = <0>;
|
||||
|
||||
/* generic regulator properties */
|
||||
regulator-name = "vdd_arm";
|
||||
regulator-min-microvolt = <770000>;
|
||||
regulator-max-microvolt = <1400000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
* Maxim MAX8973 Voltage Regulator
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be one of following:
|
||||
"maxim,max8973"
|
||||
"maxim,max77621".
|
||||
- reg: the i2c slave address of the regulator. It should be 0x1b.
|
||||
|
||||
Any standard regulator properties can be used to configure the single max8973
|
||||
DCDC.
|
||||
|
||||
Optional properties:
|
||||
|
||||
-maxim,externally-enable: boolean, externally control the regulator output
|
||||
enable/disable.
|
||||
-maxim,enable-gpio: GPIO for enable control. If the valid GPIO is provided
|
||||
then externally enable control will be considered.
|
||||
-maxim,dvs-gpio: GPIO which is connected to DVS pin of device.
|
||||
-maxim,dvs-default-state: Default state of GPIO during initialisation.
|
||||
1 for HIGH and 0 for LOW.
|
||||
-maxim,enable-remote-sense: boolean, enable reote sense.
|
||||
-maxim,enable-falling-slew-rate: boolean, enable falling slew rate.
|
||||
-maxim,enable-active-discharge: boolean: enable active discharge.
|
||||
-maxim,enable-frequency-shift: boolean, enable 9% frequency shift.
|
||||
-maxim,enable-bias-control: boolean, enable bias control. By enabling this
|
||||
startup delay can be reduce to 20us from 220us.
|
||||
-maxim,enable-etr: boolean, enable Enhanced Transient Response.
|
||||
-maxim,enable-high-etr-sensitivity: boolean, Enhanced transient response
|
||||
circuit is enabled and set for high sensitivity. If this
|
||||
property is available then etr will be enable default.
|
||||
|
||||
Enhanced transient response (ETR) will affect the configuration of CKADV.
|
||||
|
||||
-junction-warn-millicelsius: u32, junction warning temperature threshold
|
||||
in millicelsius. If die temperature crosses this level then
|
||||
device generates the warning interrupts.
|
||||
|
||||
Please note that thermal functionality is only supported on MAX77621. The
|
||||
supported threshold warning temperature for MAX77621 are 120 degC and 140 degC.
|
||||
|
||||
Example:
|
||||
|
||||
max8973@1b {
|
||||
compatible = "maxim,max8973";
|
||||
reg = <0x1b>;
|
||||
|
||||
regulator-min-microvolt = <935000>;
|
||||
regulator-max-microvolt = <1200000>;
|
||||
regulator-boot-on;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
|
@ -1,145 +0,0 @@
|
|||
* Maxim MAX8997 Voltage and Current Regulator
|
||||
|
||||
The Maxim MAX8997 is a multi-function device which includes voltage and
|
||||
current regulators, rtc, charger controller and other sub-blocks. It is
|
||||
interfaced to the host controller using a i2c interface. Each sub-block is
|
||||
addressed by the host system using different i2c slave address. This document
|
||||
describes the bindings for 'pmic' sub-block of max8997.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "maxim,max8997-pmic".
|
||||
- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
|
||||
|
||||
- max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
|
||||
units for buck1 when changing voltage using gpio dvs. Refer to [1] below
|
||||
for additional information.
|
||||
|
||||
- max8997,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
|
||||
units for buck2 when changing voltage using gpio dvs. Refer to [1] below
|
||||
for additional information.
|
||||
|
||||
- max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
|
||||
units for buck5 when changing voltage using gpio dvs. Refer to [1] below
|
||||
for additional information.
|
||||
|
||||
[1] If none of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
|
||||
property is specified, the 'max8997,pmic-buck[1/2/5]-dvs-voltage'
|
||||
property should specify atleast one voltage level (which would be a
|
||||
safe operating voltage).
|
||||
|
||||
If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
|
||||
property is specified, then all the eight voltage values for the
|
||||
'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified.
|
||||
|
||||
Optional properties:
|
||||
- interrupts: Interrupt specifiers for two interrupt sources.
|
||||
- First interrupt specifier is for 'irq1' interrupt.
|
||||
- Second interrupt specifier is for 'alert' interrupt.
|
||||
- charger-supply: regulator node for charging current.
|
||||
- max8997,pmic-buck1-uses-gpio-dvs: 'buck1' can be controlled by gpio dvs.
|
||||
- max8997,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
|
||||
- max8997,pmic-buck5-uses-gpio-dvs: 'buck5' can be controlled by gpio dvs.
|
||||
|
||||
Additional properties required if either of the optional properties are used:
|
||||
- max8997,pmic-ignore-gpiodvs-side-effect: When GPIO-DVS mode is used for
|
||||
multiple bucks, changing the voltage value of one of the bucks may affect
|
||||
that of another buck, which is the side effect of the change (set_voltage).
|
||||
Use this property to ignore such side effects and change the voltage.
|
||||
|
||||
- max8997,pmic-buck125-default-dvs-idx: Default voltage setting selected from
|
||||
the possible 8 options selectable by the dvs gpios. The value of this
|
||||
property should be between 0 and 7. If not specified or if out of range, the
|
||||
default value of this property is set to 0.
|
||||
|
||||
- max8997,pmic-buck125-dvs-gpios: GPIO specifiers for three host gpio's used
|
||||
for dvs. The format of the gpio specifier depends in the gpio controller.
|
||||
|
||||
Regulators: The regulators of max8997 that have to be instantiated should be
|
||||
included in a sub-node named 'regulators'. Regulator nodes included in this
|
||||
sub-node should be of the format as listed below.
|
||||
|
||||
regulator_name {
|
||||
standard regulator bindings here
|
||||
};
|
||||
|
||||
The following are the names of the regulators that the max8997 pmic block
|
||||
supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
|
||||
as per the datasheet of max8997.
|
||||
|
||||
- LDOn
|
||||
- valid values for n are 1 to 18 and 21
|
||||
- Example: LDO0, LD01, LDO2, LDO21
|
||||
- BUCKn
|
||||
- valid values for n are 1 to 7.
|
||||
- Example: BUCK1, BUCK2, BUCK3, BUCK7
|
||||
|
||||
- ENVICHG: Battery Charging Current Monitor Output. This is a fixed
|
||||
voltage type regulator
|
||||
|
||||
- ESAFEOUT1: (ldo19)
|
||||
- ESAFEOUT2: (ld020)
|
||||
|
||||
- CHARGER_CV: main battery charger voltage control
|
||||
- CHARGER: main battery charger current control
|
||||
- CHARGER_TOPOFF: end of charge current threshold level
|
||||
|
||||
The bindings inside the regulator nodes use the standard regulator bindings
|
||||
which are documented elsewhere.
|
||||
|
||||
Example:
|
||||
|
||||
max8997_pmic@66 {
|
||||
compatible = "maxim,max8997-pmic";
|
||||
interrupt-parent = <&wakeup_eint>;
|
||||
reg = <0x66>;
|
||||
interrupts = <4 0>, <3 0>;
|
||||
|
||||
max8997,pmic-buck1-uses-gpio-dvs;
|
||||
max8997,pmic-buck2-uses-gpio-dvs;
|
||||
max8997,pmic-buck5-uses-gpio-dvs;
|
||||
|
||||
max8997,pmic-ignore-gpiodvs-side-effect;
|
||||
max8997,pmic-buck125-default-dvs-idx = <0>;
|
||||
|
||||
max8997,pmic-buck125-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */
|
||||
<&gpx0 1 1 0 0>, /* SET2 */
|
||||
<&gpx0 2 1 0 0>; /* SET3 */
|
||||
|
||||
max8997,pmic-buck1-dvs-voltage = <1350000>, <1300000>,
|
||||
<1250000>, <1200000>,
|
||||
<1150000>, <1100000>,
|
||||
<1000000>, <950000>;
|
||||
|
||||
max8997,pmic-buck2-dvs-voltage = <1100000>, <1100000>,
|
||||
<1100000>, <1100000>,
|
||||
<1000000>, <1000000>,
|
||||
<1000000>, <1000000>;
|
||||
|
||||
max8997,pmic-buck5-dvs-voltage = <1200000>, <1200000>,
|
||||
<1200000>, <1200000>,
|
||||
<1200000>, <1200000>,
|
||||
<1200000>, <1200000>;
|
||||
|
||||
regulators {
|
||||
ldo1_reg: LDO1 {
|
||||
regulator-name = "VDD_ABB_3.3V";
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
};
|
||||
|
||||
ldo2_reg: LDO2 {
|
||||
regulator-name = "VDD_ALIVE_1.1V";
|
||||
regulator-min-microvolt = <1100000>;
|
||||
regulator-max-microvolt = <1100000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
buck1_reg: BUCK1 {
|
||||
regulator-name = "VDD_ARM_1.2V";
|
||||
regulator-min-microvolt = <950000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,109 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/maxim,max8952.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Maxim MAX8952 voltage regulator
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
allOf:
|
||||
- $ref: regulator.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: maxim,max8952
|
||||
|
||||
max8952,default-mode:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 1, 2, 3]
|
||||
description: |
|
||||
index of default DVS voltage
|
||||
|
||||
max8952,dvs-mode-microvolt:
|
||||
minItems: 4
|
||||
maxItems: 4
|
||||
items:
|
||||
minimum: 770000
|
||||
maximum: 1400000
|
||||
description: |
|
||||
Array of 4 integer values defining DVS voltages in microvolts. All values
|
||||
must be from range <770000, 1400000>.
|
||||
|
||||
max8952,en-gpio:
|
||||
maxItems: 1
|
||||
description: |
|
||||
GPIO used to control enable status of regulator
|
||||
|
||||
max8952,ramp-speed:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 1, 2, 3, 4, 5, 6, 7]
|
||||
default: 0
|
||||
description: |
|
||||
Voltage ramp speed, values map to:
|
||||
- 0: 32mV/us
|
||||
- 1: 16mV/us
|
||||
- 2: 8mV/us
|
||||
- 3: 4mV/us
|
||||
- 4: 2mV/us
|
||||
- 5: 1mV/us
|
||||
- 6: 0.5mV/us
|
||||
- 7: 0.25mV/us
|
||||
Defaults to 32mV/us if not specified.
|
||||
|
||||
max8952,sync-freq:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 1, 2]
|
||||
default: 0
|
||||
description: |
|
||||
Sync frequency, values map to:
|
||||
- 0: 26 MHz
|
||||
- 1: 13 MHz
|
||||
- 2: 19.2 MHz
|
||||
Defaults to 26 MHz if not specified.
|
||||
|
||||
max8952,vid-gpios:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
description: |
|
||||
Array of two GPIO pins used for DVS voltage selection
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- max8952,dvs-mode-microvolt
|
||||
- reg
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
pmic@60 {
|
||||
compatible = "maxim,max8952";
|
||||
reg = <0x60>;
|
||||
|
||||
max8952,vid-gpios = <&gpx0 3 GPIO_ACTIVE_HIGH>,
|
||||
<&gpx0 4 GPIO_ACTIVE_HIGH>;
|
||||
max8952,default-mode = <0>;
|
||||
max8952,dvs-mode-microvolt = <1250000>, <1200000>,
|
||||
<1050000>, <950000>;
|
||||
max8952,sync-freq = <0>;
|
||||
max8952,ramp-speed = <0>;
|
||||
|
||||
regulator-name = "VARM_1.2V_C210";
|
||||
regulator-min-microvolt = <770000>;
|
||||
regulator-max-microvolt = <1400000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,139 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/maxim,max8973.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Maxim MAX8973/MAX77621 voltage regulator
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
allOf:
|
||||
- $ref: regulator.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- maxim,max8973
|
||||
- maxim,max77621
|
||||
|
||||
junction-warn-millicelsius:
|
||||
description: |
|
||||
Junction warning temperature threshold in millicelsius. If die
|
||||
temperature crosses this level then device generates the warning
|
||||
interrupts.
|
||||
Please note that thermal functionality is only supported on MAX77621. The
|
||||
supported threshold warning temperature for MAX77621 are 120 degC and 140
|
||||
degC.
|
||||
|
||||
maxim,dvs-gpio:
|
||||
maxItems: 1
|
||||
description: |
|
||||
GPIO which is connected to DVS pin of device.
|
||||
|
||||
maxim,dvs-default-state:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 1]
|
||||
description: |
|
||||
Default state of GPIO during initialisation.
|
||||
1 for HIGH and 0 for LOW.
|
||||
|
||||
maxim,externally-enable:
|
||||
type: boolean
|
||||
description: |
|
||||
Externally control the regulator output enable/disable.
|
||||
|
||||
maxim,enable-gpio:
|
||||
maxItems: 1
|
||||
description: |
|
||||
GPIO for enable control. If the valid GPIO is provided then externally
|
||||
enable control will be considered.
|
||||
|
||||
maxim,enable-remote-sense:
|
||||
type: boolean
|
||||
description: Enable remote sense.
|
||||
|
||||
maxim,enable-falling-slew-rate:
|
||||
type: boolean
|
||||
description: Enable falling slew rate.
|
||||
|
||||
maxim,enable-active-discharge:
|
||||
type: boolean
|
||||
description: Eable active discharge.
|
||||
|
||||
maxim,enable-frequency-shift:
|
||||
type: boolean
|
||||
description: Enable 9% frequency shift.
|
||||
|
||||
maxim,enable-bias-control:
|
||||
type: boolean
|
||||
description: |
|
||||
Enable bias control which can reduce the startup delay to 20us from 220us.
|
||||
|
||||
maxim,enable-etr:
|
||||
type: boolean
|
||||
description: Enable Enhanced Transient Response.
|
||||
|
||||
maxim,enable-high-etr-sensitivity:
|
||||
type: boolean
|
||||
description: |
|
||||
Enhanced transient response circuit is enabled and set for high
|
||||
sensitivity. If this property is available then etr will be enable
|
||||
default.
|
||||
Enhanced transient response (ETR) will affect the configuration of CKADV.
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
regulator@1b {
|
||||
compatible = "maxim,max8973";
|
||||
reg = <0x1b>;
|
||||
|
||||
regulator-min-microvolt = <935000>;
|
||||
regulator-max-microvolt = <1200000>;
|
||||
regulator-boot-on;
|
||||
regulator-always-on;
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
#include <dt-bindings/gpio/tegra-gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
regulator@1b {
|
||||
compatible = "maxim,max77621";
|
||||
reg = <0x1b>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <TEGRA_GPIO(Y, 1) IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
regulator-min-microvolt = <800000>;
|
||||
regulator-max-microvolt = <1231250>;
|
||||
regulator-name = "PPVAR_CPU";
|
||||
regulator-ramp-delay = <12500>;
|
||||
maxim,dvs-default-state = <1>;
|
||||
maxim,enable-active-discharge;
|
||||
maxim,enable-bias-control;
|
||||
maxim,enable-etr;
|
||||
maxim,enable-gpio = <&pmic 5 GPIO_ACTIVE_HIGH>;
|
||||
maxim,externally-enable;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,445 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/maxim,max8997.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Maxim MAX8997 Power Management IC
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
description: |
|
||||
The Maxim MAX8997 is a Power Management IC which includes voltage and current
|
||||
regulators, charger controller with fuel gauge, RTC, clock outputs, haptic
|
||||
motor driver, flash LED driver and Micro-USB Interface Controller.
|
||||
|
||||
The binding here is not complete and describes only regulator and charger
|
||||
controller parts.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: maxim,max8997-pmic
|
||||
|
||||
charger-supply:
|
||||
description: |
|
||||
Regulator node for charging current.
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: irq1 interrupt
|
||||
- description: alert interrupt
|
||||
|
||||
max8997,pmic-buck1-dvs-voltage:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 1
|
||||
maxItems: 8
|
||||
description: |
|
||||
A set of 8 voltage values in micro-volt (uV) units for buck1 when
|
||||
changing voltage using GPIO DVS.
|
||||
If none of max8997,pmic-buck[1/2/5]-uses-gpio-dvs optional property is
|
||||
specified, the max8997,pmic-buck[1/2/5]-dvs-voltage property should
|
||||
specify at least one voltage level (which would be a safe operating
|
||||
voltage).
|
||||
|
||||
max8997,pmic-buck2-dvs-voltage:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 1
|
||||
maxItems: 8
|
||||
description: |
|
||||
A set of 8 voltage values in micro-volt (uV) units for buck2 when
|
||||
changing voltage using GPIO DVS.
|
||||
If none of max8997,pmic-buck[1/2/5]-uses-gpio-dvs optional property is
|
||||
specified, the max8997,pmic-buck[1/2/5]-dvs-voltage property should
|
||||
specify at least one voltage level (which would be a safe operating
|
||||
voltage).
|
||||
|
||||
max8997,pmic-buck5-dvs-voltage:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 1
|
||||
maxItems: 8
|
||||
description: |
|
||||
A set of 8 voltage values in micro-volt (uV) units for buck5 when
|
||||
changing voltage using GPIO DVS.
|
||||
If none of max8997,pmic-buck[1/2/5]-uses-gpio-dvs optional property is
|
||||
specified, the max8997,pmic-buck[1/2/5]-dvs-voltage property should
|
||||
specify at least one voltage level (which would be a safe operating
|
||||
voltage).
|
||||
|
||||
max8997,pmic-buck1-uses-gpio-dvs:
|
||||
type: boolean
|
||||
description: |
|
||||
buck1 can be controlled by GPIO DVS.
|
||||
|
||||
max8997,pmic-buck2-uses-gpio-dvs:
|
||||
type: boolean
|
||||
description: |
|
||||
buck2 can be controlled by GPIO DVS.
|
||||
|
||||
max8997,pmic-buck5-uses-gpio-dvs:
|
||||
type: boolean
|
||||
description: |
|
||||
buck5 can be controlled by GPIO DVS.
|
||||
|
||||
max8997,pmic-buck125-default-dvs-idx:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 0
|
||||
maximum: 7
|
||||
default: 0
|
||||
description: |
|
||||
Default voltage setting selected from the possible 8 options selectable
|
||||
by the dvs gpios. The value of this property should be between 0 and 7.
|
||||
If not specified or if out of range, the default value of this property
|
||||
is set to 0.
|
||||
|
||||
max8997,pmic-buck125-dvs-gpios:
|
||||
minItems: 3
|
||||
maxItems: 3
|
||||
description: |
|
||||
GPIO specifiers for three host gpio's used for DVS.
|
||||
|
||||
max8997,pmic-ignore-gpiodvs-side-effect:
|
||||
type: boolean
|
||||
description: |
|
||||
When GPIO-DVS mode is used for multiple bucks, changing the voltage value
|
||||
of one of the bucks may affect that of another buck, which is the side
|
||||
effect of the change (set_voltage). Use this property to ignore such
|
||||
side effects and change the voltage.
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
regulators:
|
||||
type: object
|
||||
description:
|
||||
List of child nodes that specify the regulators.
|
||||
|
||||
patternProperties:
|
||||
# 1-18 and 21 LDOs
|
||||
"^LDO([1-9]|1[0-8]|21)$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
description:
|
||||
Properties for single LDO regulator.
|
||||
|
||||
properties:
|
||||
regulator-name: true
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
# 7 bucks
|
||||
"^BUCK[1-7]$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
description:
|
||||
Properties for single BUCK regulator.
|
||||
|
||||
properties:
|
||||
regulator-name: true
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
"^EN32KHZ_[AC]P$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
description:
|
||||
32768 Hz clock output (modelled as regulator)
|
||||
|
||||
properties:
|
||||
regulator-name: true
|
||||
regulator-always-on: true
|
||||
regulator-boot-on: true
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
CHARGER:
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
description: main battery charger current control
|
||||
|
||||
properties:
|
||||
regulator-name: true
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
CHARGER_CV:
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
description: main battery charger voltage control
|
||||
|
||||
properties:
|
||||
regulator-name: true
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
CHARGER_TOPOFF:
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
description: end of charge current threshold level
|
||||
|
||||
properties:
|
||||
regulator-name: true
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
ENVICHG:
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
description: |
|
||||
Battery Charging Current Monitor Output. This is a fixed voltage type
|
||||
regulator
|
||||
properties:
|
||||
regulator-name: true
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
ESAFEOUT1:
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
description: LDO19
|
||||
|
||||
properties:
|
||||
regulator-name: true
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
ESAFEOUT2:
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
description: LDO20
|
||||
|
||||
properties:
|
||||
regulator-name: true
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- max8997,pmic-buck1-dvs-voltage
|
||||
- max8997,pmic-buck2-dvs-voltage
|
||||
- max8997,pmic-buck5-dvs-voltage
|
||||
- reg
|
||||
- regulators
|
||||
|
||||
dependencies:
|
||||
max8997,pmic-buck1-uses-gpio-dvs: [ 'max8997,pmic-buck125-dvs-gpios' ]
|
||||
max8997,pmic-buck2-uses-gpio-dvs: [ 'max8997,pmic-buck125-dvs-gpios' ]
|
||||
max8997,pmic-buck5-uses-gpio-dvs: [ 'max8997,pmic-buck125-dvs-gpios' ]
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
if:
|
||||
anyOf:
|
||||
- required:
|
||||
- max8997,pmic-buck1-uses-gpio-dvs
|
||||
- required:
|
||||
- max8997,pmic-buck2-uses-gpio-dvs
|
||||
- required:
|
||||
- max8997,pmic-buck5-uses-gpio-dvs
|
||||
then:
|
||||
properties:
|
||||
max8997,pmic-buck1-dvs-voltage:
|
||||
minItems: 8
|
||||
maxItems: 8
|
||||
max8997,pmic-buck2-dvs-voltage:
|
||||
minItems: 8
|
||||
maxItems: 8
|
||||
max8997,pmic-buck5-dvs-voltage:
|
||||
minItems: 8
|
||||
maxItems: 8
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
pmic@66 {
|
||||
compatible = "maxim,max8997-pmic";
|
||||
reg = <0x66>;
|
||||
|
||||
interrupts-extended = <&gpx0 7 IRQ_TYPE_LEVEL_LOW>,
|
||||
<&gpx2 3 IRQ_TYPE_EDGE_FALLING>;
|
||||
|
||||
max8997,pmic-buck1-uses-gpio-dvs;
|
||||
max8997,pmic-buck2-uses-gpio-dvs;
|
||||
max8997,pmic-buck5-uses-gpio-dvs;
|
||||
|
||||
max8997,pmic-ignore-gpiodvs-side-effect;
|
||||
max8997,pmic-buck125-default-dvs-idx = <0>;
|
||||
|
||||
max8997,pmic-buck125-dvs-gpios = <&gpx0 5 GPIO_ACTIVE_HIGH>,
|
||||
<&gpx0 6 GPIO_ACTIVE_HIGH>,
|
||||
<&gpl0 0 GPIO_ACTIVE_HIGH>;
|
||||
|
||||
max8997,pmic-buck1-dvs-voltage = <1350000>, <1300000>,
|
||||
<1250000>, <1200000>,
|
||||
<1150000>, <1100000>,
|
||||
<1000000>, <950000>;
|
||||
|
||||
max8997,pmic-buck2-dvs-voltage = <1100000>, <1000000>,
|
||||
<950000>, <900000>,
|
||||
<1100000>, <1000000>,
|
||||
<950000>, <900000>;
|
||||
|
||||
max8997,pmic-buck5-dvs-voltage = <1200000>, <1200000>,
|
||||
<1200000>, <1200000>,
|
||||
<1200000>, <1200000>,
|
||||
<1200000>, <1200000>;
|
||||
|
||||
pinctrl-0 = <&max8997_irq>, <&otg_gp>, <&usb_sel>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
charger-supply = <&charger_reg>;
|
||||
|
||||
regulators {
|
||||
LDO1 {
|
||||
regulator-name = "VADC_3.3V_C210";
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
LDO2 {
|
||||
regulator-name = "VALIVE_1.1V_C210";
|
||||
regulator-min-microvolt = <1100000>;
|
||||
regulator-max-microvolt = <1100000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
BUCK1 {
|
||||
regulator-name = "VARM_1.2V_C210";
|
||||
regulator-min-microvolt = <65000>;
|
||||
regulator-max-microvolt = <2225000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
// ...
|
||||
|
||||
BUCK7 {
|
||||
regulator-name = "VCC_SUB_2.0V";
|
||||
regulator-min-microvolt = <2000000>;
|
||||
regulator-max-microvolt = <2000000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
ESAFEOUT1 {
|
||||
regulator-name = "SAFEOUT1";
|
||||
};
|
||||
|
||||
ESAFEOUT2 {
|
||||
regulator-name = "SAFEOUT2";
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
EN32KHZ_AP {
|
||||
regulator-name = "EN32KHZ_AP";
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
EN32KHZ_CP {
|
||||
regulator-name = "EN32KHZ_CP";
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
CHARGER {
|
||||
regulator-name = "CHARGER";
|
||||
regulator-min-microamp = <200000>;
|
||||
regulator-max-microamp = <950000>;
|
||||
};
|
||||
|
||||
CHARGER_CV {
|
||||
regulator-name = "CHARGER_CV";
|
||||
regulator-min-microvolt = <4200000>;
|
||||
regulator-max-microvolt = <4200000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
CHARGER_TOPOFF {
|
||||
regulator-name = "CHARGER_TOPOFF";
|
||||
regulator-min-microamp = <200000>;
|
||||
regulator-max-microamp = <200000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
pmic@66 {
|
||||
compatible = "maxim,max8997-pmic";
|
||||
reg = <0x66>;
|
||||
|
||||
interrupt-parent = <&gpx0>;
|
||||
interrupts = <4 IRQ_TYPE_LEVEL_LOW>,
|
||||
<3 IRQ_TYPE_EDGE_FALLING>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&max8997_irq>;
|
||||
|
||||
max8997,pmic-buck1-dvs-voltage = <1350000>;
|
||||
max8997,pmic-buck2-dvs-voltage = <1100000>;
|
||||
max8997,pmic-buck5-dvs-voltage = <1200000>;
|
||||
|
||||
regulators {
|
||||
LDO1 {
|
||||
regulator-name = "VDD_ABB_3.3V";
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
};
|
||||
|
||||
// ...
|
||||
|
||||
BUCK1 {
|
||||
regulator-name = "VDD_ARM_1.2V";
|
||||
regulator-min-microvolt = <950000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
// ...
|
||||
|
||||
EN32KHZ_AP {
|
||||
regulator-name = "EN32KHZ_AP";
|
||||
regulator-always-on;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -35,6 +35,7 @@ description: |
|
|||
PMIC. Supported regulator node names are
|
||||
For PM6150, smps1 - smps5, ldo1 - ldo19
|
||||
For PM6150L, smps1 - smps8, ldo1 - ldo11, bob
|
||||
For PM6350, smps1 - smps5, ldo1 - ldo22
|
||||
For PM7325, smps1 - smps8, ldo1 - ldo19
|
||||
For PM8005, smps1 - smps4
|
||||
For PM8009, smps1 - smps2, ldo1 - ldo7
|
||||
|
|
@ -52,6 +53,7 @@ properties:
|
|||
enum:
|
||||
- qcom,pm6150-rpmh-regulators
|
||||
- qcom,pm6150l-rpmh-regulators
|
||||
- qcom,pm6350-rpmh-regulators
|
||||
- qcom,pm7325-rpmh-regulators
|
||||
- qcom,pm8005-rpmh-regulators
|
||||
- qcom,pm8009-rpmh-regulators
|
||||
|
|
|
|||
|
|
@ -65,6 +65,9 @@ description:
|
|||
For pms405, s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
|
||||
l12, l13
|
||||
|
||||
For pm2250, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
|
||||
l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22
|
||||
|
||||
maintainers:
|
||||
- Kathiravan T <kathirav@codeaurora.org>
|
||||
|
||||
|
|
@ -86,6 +89,7 @@ properties:
|
|||
- qcom,rpm-pmi8994-regulators
|
||||
- qcom,rpm-pmi8998-regulators
|
||||
- qcom,rpm-pms405-regulators
|
||||
- qcom,rpm-pm2250-regulators
|
||||
|
||||
patternProperties:
|
||||
".*-supply$":
|
||||
|
|
|
|||
|
|
@ -1,79 +0,0 @@
|
|||
Binding for Samsung S2MPA01 regulator block
|
||||
===========================================
|
||||
|
||||
This is a part of device tree bindings for S2M family multi-function devices.
|
||||
More information can be found in bindings/mfd/sec-core.txt file.
|
||||
|
||||
The S2MPA01 device provide buck and LDO regulators.
|
||||
|
||||
To register these with regulator framework instantiate under main device node
|
||||
a sub-node named "regulators" with more sub-nodes for each regulator using the
|
||||
common regulator binding documented in:
|
||||
- Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
|
||||
|
||||
Names of regulators supported by S2MPA01 device:
|
||||
- LDOn
|
||||
- valid values for n are 1 to 26
|
||||
- Example: LDO1, LD02, LDO26
|
||||
- BUCKn
|
||||
- valid values for n are 1 to 10.
|
||||
- Example: BUCK1, BUCK2, BUCK9
|
||||
Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
|
||||
as per the datasheet of device.
|
||||
|
||||
|
||||
Optional properties of buck regulator nodes under "regulators" sub-node:
|
||||
- regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500
|
||||
(default), 25000, or 50000. May be 0 for disabling the ramp delay on
|
||||
BUCK{1,2,3,4}.
|
||||
|
||||
In the absence of the regulator-ramp-delay property, the default ramp
|
||||
delay will be used.
|
||||
|
||||
Note: Some bucks share the ramp rate setting i.e. same ramp value
|
||||
will be set for a particular group of bucks so provide the same
|
||||
regulator-ramp-delay value for them.
|
||||
Groups sharing ramp rate:
|
||||
- buck{1,6},
|
||||
- buck{2,4},
|
||||
- buck{8,9,10}.
|
||||
|
||||
Example:
|
||||
|
||||
s2mpa01_pmic@66 {
|
||||
compatible = "samsung,s2mpa01-pmic";
|
||||
reg = <0x66>;
|
||||
|
||||
regulators {
|
||||
ldo1_reg: LDO1 {
|
||||
regulator-name = "VDD_ALIVE";
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <1000000>;
|
||||
};
|
||||
|
||||
ldo2_reg: LDO2 {
|
||||
regulator-name = "VDDQ_MMC2";
|
||||
regulator-min-microvolt = <2800000>;
|
||||
regulator-max-microvolt = <2800000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
buck1_reg: BUCK1 {
|
||||
regulator-name = "vdd_mif";
|
||||
regulator-min-microvolt = <950000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
buck2_reg: BUCK2 {
|
||||
regulator-name = "vdd_arm";
|
||||
regulator-min-microvolt = <950000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
regulator-ramp-delay = <50000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/samsung,s2mpa01.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S2MPA01 Power Management IC regulators
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
description: |
|
||||
This is a part of device tree bindings for S2M and S5M family of Power
|
||||
Management IC (PMIC).
|
||||
|
||||
The S2MPA01 provides buck and LDO regulators.
|
||||
|
||||
See also Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml for
|
||||
additional information and example.
|
||||
|
||||
patternProperties:
|
||||
# 26 LDOs
|
||||
"^LDO([1-9]|1[0-9]|2[0-6])$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single LDO regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
# 10 bucks
|
||||
"^BUCK([1-9]|10)$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single BUCK regulator.
|
||||
|
||||
properties:
|
||||
regulator-ramp-delay:
|
||||
enum: [0, 6250, 12500, 25000, 50000]
|
||||
default: 12500
|
||||
description: |
|
||||
May be 0 for disabling the ramp delay on BUCK{1,2,3,4}.
|
||||
|
||||
In the absence of the regulator-ramp-delay property, the default ramp
|
||||
delay will be used.
|
||||
|
||||
Note: Some bucks share the ramp rate setting i.e. same ramp value
|
||||
will be set for a particular group of bucks so provide the same
|
||||
regulator-ramp-delay value for them.
|
||||
Groups sharing ramp rate:
|
||||
* buck{1,6},
|
||||
* buck{2,4},
|
||||
* buck{8,9,10}.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
additionalProperties: false
|
||||
|
|
@ -1,102 +0,0 @@
|
|||
Binding for Samsung S2M family regulator block
|
||||
==============================================
|
||||
|
||||
This is a part of device tree bindings for S2M family multi-function devices.
|
||||
More information can be found in bindings/mfd/sec-core.txt file.
|
||||
|
||||
The S2MPS11/13/14/15 and S2MPU02 devices provide buck and LDO regulators.
|
||||
|
||||
To register these with regulator framework instantiate under main device node
|
||||
a sub-node named "regulators" with more sub-nodes for each regulator using the
|
||||
common regulator binding documented in:
|
||||
- Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
|
||||
|
||||
Names of regulators supported by different devices:
|
||||
- LDOn
|
||||
- valid values for n are:
|
||||
- S2MPS11: 1 to 38
|
||||
- S2MPS13: 1 to 40
|
||||
- S2MPS14: 1 to 25
|
||||
- S2MPS15: 1 to 27
|
||||
- S2MPU02: 1 to 28
|
||||
- Example: LDO1, LDO2, LDO28
|
||||
- BUCKn
|
||||
- valid values for n are:
|
||||
- S2MPS11: 1 to 10
|
||||
- S2MPS13: 1 to 10
|
||||
- S2MPS14: 1 to 5
|
||||
- S2MPS15: 1 to 10
|
||||
- S2MPU02: 1 to 7
|
||||
- Example: BUCK1, BUCK2, BUCK9
|
||||
Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
|
||||
as per the datasheet of device.
|
||||
|
||||
|
||||
Optional properties of the nodes under "regulators" sub-node:
|
||||
- regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500,
|
||||
25000 (default) or 50000.
|
||||
|
||||
Additionally S2MPS11 supports disabling ramp delay for BUCK{2,3,4,6}
|
||||
by setting it to <0>.
|
||||
|
||||
Note: On S2MPS11 some bucks share the ramp rate setting i.e. same ramp value
|
||||
will be set for a particular group of bucks so provide the same
|
||||
regulator-ramp-delay value for them.
|
||||
Groups sharing ramp rate:
|
||||
- buck{1,6},
|
||||
- buck{3,4},
|
||||
- buck{7,8,10}.
|
||||
|
||||
- samsung,ext-control-gpios: On S2MPS14 the LDO10, LDO11 and LDO12 can be
|
||||
configured to external control over GPIO. To turn this feature on this
|
||||
property must be added to the regulator sub-node:
|
||||
- samsung,ext-control-gpios: GPIO specifier for one GPIO
|
||||
controlling this regulator (enable/disable)
|
||||
Example:
|
||||
LDO12 {
|
||||
regulator-name = "V_EMMC_2.8V";
|
||||
regulator-min-microvolt = <2800000>;
|
||||
regulator-max-microvolt = <2800000>;
|
||||
samsung,ext-control-gpios = <&gpk0 2 0>;
|
||||
};
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
s2mps11_pmic@66 {
|
||||
compatible = "samsung,s2mps11-pmic";
|
||||
reg = <0x66>;
|
||||
|
||||
regulators {
|
||||
ldo1_reg: LDO1 {
|
||||
regulator-name = "VDD_ABB_3.3V";
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
};
|
||||
|
||||
ldo2_reg: LDO2 {
|
||||
regulator-name = "VDD_ALIVE_1.1V";
|
||||
regulator-min-microvolt = <1100000>;
|
||||
regulator-max-microvolt = <1100000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
buck1_reg: BUCK1 {
|
||||
regulator-name = "vdd_mif";
|
||||
regulator-min-microvolt = <950000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
buck2_reg: BUCK2 {
|
||||
regulator-name = "vdd_arm";
|
||||
regulator-min-microvolt = <950000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
regulator-ramp-delay = <50000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/samsung,s2mps11.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S2MPS11 Power Management IC regulators
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
description: |
|
||||
This is a part of device tree bindings for S2M and S5M family of Power
|
||||
Management IC (PMIC).
|
||||
|
||||
The S2MPS11 provides buck and LDO regulators.
|
||||
|
||||
See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
|
||||
additional information and example.
|
||||
|
||||
patternProperties:
|
||||
# 38 LDOs
|
||||
"^LDO([1-9]|[1-2][0-9]|3[0-8])$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single LDO regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
# 10 bucks
|
||||
"^BUCK([1-9]|10)$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single BUCK regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
additionalProperties: false
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/samsung,s2mps13.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S2MPS13 Power Management IC regulators
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
description: |
|
||||
This is a part of device tree bindings for S2M and S5M family of Power
|
||||
Management IC (PMIC).
|
||||
|
||||
The S2MPS13 provides buck and LDO regulators.
|
||||
|
||||
See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
|
||||
additional information and example.
|
||||
|
||||
patternProperties:
|
||||
# 40 LDOs
|
||||
"^LDO([1-9]|[1-3][0-9]|40)$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single LDO regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
# 10 bucks
|
||||
"^BUCK([1-9]|10)$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single BUCK regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
additionalProperties: false
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/samsung,s2mps14.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S2MPS14 Power Management IC regulators
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
description: |
|
||||
This is a part of device tree bindings for S2M and S5M family of Power
|
||||
Management IC (PMIC).
|
||||
|
||||
The S2MPS14 provides buck and LDO regulators.
|
||||
|
||||
See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
|
||||
additional information and example.
|
||||
|
||||
patternProperties:
|
||||
# 25 LDOs
|
||||
"^LDO([1-9]|[1][0-9]|2[0-5])$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single LDO regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
# 5 bucks
|
||||
"^BUCK[1-5]$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single BUCK regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
additionalProperties: false
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/samsung,s2mps15.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S2MPS15 Power Management IC regulators
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
description: |
|
||||
This is a part of device tree bindings for S2M and S5M family of Power
|
||||
Management IC (PMIC).
|
||||
|
||||
The S2MPS15 provides buck and LDO regulators.
|
||||
|
||||
See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
|
||||
additional information and example.
|
||||
|
||||
patternProperties:
|
||||
# 27 LDOs
|
||||
"^LDO([1-9]|[1][0-9]|2[0-7])$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single LDO regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
# 10 bucks
|
||||
"^BUCK([1-9]|10)$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single BUCK regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
additionalProperties: false
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/samsung,s2mpu02.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S2MPU02 Power Management IC regulators
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
description: |
|
||||
This is a part of device tree bindings for S2M and S5M family of Power
|
||||
Management IC (PMIC).
|
||||
|
||||
The S2MPU02 provides buck and LDO regulators.
|
||||
|
||||
See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
|
||||
additional information and example.
|
||||
|
||||
patternProperties:
|
||||
# 28 LDOs
|
||||
"^LDO([1-9]|1[0-9]|2[0-8])$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single LDO regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
# 7 bucks
|
||||
"^BUCK[1-7]$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single BUCK regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
additionalProperties: false
|
||||
|
|
@ -1,145 +0,0 @@
|
|||
Binding for Samsung S5M8767 regulator block
|
||||
===========================================
|
||||
|
||||
This is a part of device tree bindings for S5M family multi-function devices.
|
||||
More information can be found in bindings/mfd/sec-core.txt file.
|
||||
|
||||
The S5M8767 device provide buck and LDO regulators.
|
||||
|
||||
To register these with regulator framework instantiate under main device node
|
||||
a sub-node named "regulators" with more sub-nodes for each regulator using the
|
||||
common regulator binding documented in:
|
||||
- Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
|
||||
|
||||
Required properties of the main device node (the parent!):
|
||||
- s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
|
||||
units for buck2 when changing voltage using gpio dvs. Refer to [1] below
|
||||
for additional information.
|
||||
|
||||
- s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
|
||||
units for buck3 when changing voltage using gpio dvs. Refer to [1] below
|
||||
for additional information.
|
||||
|
||||
- s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
|
||||
units for buck4 when changing voltage using gpio dvs. Refer to [1] below
|
||||
for additional information.
|
||||
|
||||
- s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used
|
||||
for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines.
|
||||
|
||||
[1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
|
||||
property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage'
|
||||
property should specify atleast one voltage level (which would be a
|
||||
safe operating voltage).
|
||||
|
||||
If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
|
||||
property is specified, then all the eight voltage values for the
|
||||
's5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified.
|
||||
|
||||
Optional properties of the main device node (the parent!):
|
||||
- s5m8767,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
|
||||
- s5m8767,pmic-buck3-uses-gpio-dvs: 'buck3' can be controlled by gpio dvs.
|
||||
- s5m8767,pmic-buck4-uses-gpio-dvs: 'buck4' can be controlled by gpio dvs.
|
||||
|
||||
Additional properties required if either of the optional properties are used:
|
||||
|
||||
- s5m8767,pmic-buck234-default-dvs-idx: Default voltage setting selected from
|
||||
the possible 8 options selectable by the dvs gpios. The value of this
|
||||
property should be between 0 and 7. If not specified or if out of range, the
|
||||
default value of this property is set to 0.
|
||||
|
||||
- s5m8767,pmic-buck-dvs-gpios: GPIO specifiers for three host gpio's used
|
||||
for dvs. The format of the gpio specifier depends in the gpio controller.
|
||||
|
||||
|
||||
Names of regulators supported by S5M8767 device:
|
||||
- LDOn
|
||||
- valid values for n are 1 to 28
|
||||
- Example: LDO1, LDO2, LDO28
|
||||
- BUCKn
|
||||
- valid values for n are 1 to 9.
|
||||
- Example: BUCK1, BUCK2, BUCK9
|
||||
Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
|
||||
as per the datasheet of device.
|
||||
|
||||
|
||||
Optional properties of the nodes under "regulators" sub-node:
|
||||
- op_mode: describes the different operating modes of the LDO's with
|
||||
power mode change in SOC. The different possible values are,
|
||||
0 - always off mode
|
||||
1 - on in normal mode
|
||||
2 - low power mode
|
||||
3 - suspend mode
|
||||
- s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one
|
||||
GPIO controlling this regulator
|
||||
(enable/disable); This is valid only
|
||||
for buck9.
|
||||
|
||||
Example:
|
||||
|
||||
s5m8767_pmic@66 {
|
||||
compatible = "samsung,s5m8767-pmic";
|
||||
reg = <0x66>;
|
||||
|
||||
s5m8767,pmic-buck2-uses-gpio-dvs;
|
||||
s5m8767,pmic-buck3-uses-gpio-dvs;
|
||||
s5m8767,pmic-buck4-uses-gpio-dvs;
|
||||
|
||||
s5m8767,pmic-buck-default-dvs-idx = <0>;
|
||||
|
||||
s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 0>, /* DVS1 */
|
||||
<&gpx0 1 0>, /* DVS2 */
|
||||
<&gpx0 2 0>; /* DVS3 */
|
||||
|
||||
s5m8767,pmic-buck-ds-gpios = <&gpx2 3 0>, /* SET1 */
|
||||
<&gpx2 4 0>, /* SET2 */
|
||||
<&gpx2 5 0>; /* SET3 */
|
||||
|
||||
s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>,
|
||||
<1250000>, <1200000>,
|
||||
<1150000>, <1100000>,
|
||||
<1000000>, <950000>;
|
||||
|
||||
s5m8767,pmic-buck3-dvs-voltage = <1100000>, <1100000>,
|
||||
<1100000>, <1100000>,
|
||||
<1000000>, <1000000>,
|
||||
<1000000>, <1000000>;
|
||||
|
||||
s5m8767,pmic-buck4-dvs-voltage = <1200000>, <1200000>,
|
||||
<1200000>, <1200000>,
|
||||
<1200000>, <1200000>,
|
||||
<1200000>, <1200000>;
|
||||
|
||||
regulators {
|
||||
ldo1_reg: LDO1 {
|
||||
regulator-name = "VDD_ABB_3.3V";
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
op_mode = <1>; /* Normal Mode */
|
||||
};
|
||||
|
||||
ldo2_reg: LDO2 {
|
||||
regulator-name = "VDD_ALIVE_1.1V";
|
||||
regulator-min-microvolt = <1100000>;
|
||||
regulator-max-microvolt = <1100000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
buck1_reg: BUCK1 {
|
||||
regulator-name = "VDD_MIF_1.2V";
|
||||
regulator-min-microvolt = <950000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
vemmc_reg: BUCK9 {
|
||||
regulator-name = "VMEM_VDD_2.8V";
|
||||
regulator-min-microvolt = <2800000>;
|
||||
regulator-max-microvolt = <2800000>;
|
||||
op_mode = <3>; /* Standby Mode */
|
||||
s5m8767,pmic-ext-control-gpios = <&gpk0 2 0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/samsung,s5m8767.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S5M8767 Power Management IC regulators
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
|
||||
description: |
|
||||
This is a part of device tree bindings for S2M and S5M family of Power
|
||||
Management IC (PMIC).
|
||||
|
||||
The S5M8767 provides buck and LDO regulators.
|
||||
|
||||
See also Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml for
|
||||
additional information and example.
|
||||
|
||||
patternProperties:
|
||||
# 28 LDOs
|
||||
"^LDO([1-9]|1[0-9]|2[0-8])$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single LDO regulator.
|
||||
|
||||
properties:
|
||||
op_mode:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 1, 2, 3]
|
||||
default: 1
|
||||
description: |
|
||||
Describes the different operating modes of the LDO's with power mode
|
||||
change in SOC. The different possible values are:
|
||||
0 - always off mode
|
||||
1 - on in normal mode
|
||||
2 - low power mode
|
||||
3 - suspend mode
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
# 8 bucks
|
||||
"^BUCK[1-8]$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single BUCK regulator.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
# 9 buck
|
||||
"^BUCK9$":
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Properties for single BUCK regulator.
|
||||
|
||||
properties:
|
||||
s5m8767,pmic-ext-control-gpios:
|
||||
maxItems: 1
|
||||
description: |
|
||||
GPIO specifier for one GPIO controlling this regulator on/off.
|
||||
|
||||
required:
|
||||
- regulator-name
|
||||
|
||||
additionalProperties: false
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/regulator/silergy,sy8106a.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Silergy SY8106A Voltage Regulator Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Ondrej Jirman <megous@megous.com>
|
||||
|
||||
allOf:
|
||||
- $ref: regulator.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: silergy,sy8106a
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
silergy,fixed-microvolt:
|
||||
description: >
|
||||
The voltage when I2C regulating is disabled (set by external resistor
|
||||
like a fixed voltage)
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- silergy,fixed-microvolt
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
regulator@65 {
|
||||
compatible = "silergy,sy8106a";
|
||||
reg = <0x65>;
|
||||
regulator-name = "sy8106a-vdd";
|
||||
silergy,fixed-microvolt = <1200000>;
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <1400000>;
|
||||
regulator-boot-on;
|
||||
regulator-always-on;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -27,6 +27,7 @@ properties:
|
|||
- socionext,uniphier-pxs2-usb3-regulator
|
||||
- socionext,uniphier-ld20-usb3-regulator
|
||||
- socionext,uniphier-pxs3-usb3-regulator
|
||||
- socionext,uniphier-nx1-usb3-regulator
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -1,23 +0,0 @@
|
|||
SY8106A Voltage regulator
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "silergy,sy8106a"
|
||||
- reg: I2C slave address - must be <0x65>
|
||||
- silergy,fixed-microvolt - the voltage when I2C regulating is disabled (set
|
||||
by external resistor like a fixed voltage)
|
||||
|
||||
Any property defined as part of the core regulator binding, defined in
|
||||
./regulator.txt, can also be used.
|
||||
|
||||
Example:
|
||||
|
||||
sy8106a {
|
||||
compatible = "silergy,sy8106a";
|
||||
reg = <0x65>;
|
||||
regulator-name = "sy8106a-vdd";
|
||||
silergy,fixed-microvolt = <1200000>;
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <1400000>;
|
||||
regulator-boot-on;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
|
@ -11,6 +11,14 @@ maintainers:
|
|||
|
||||
allOf:
|
||||
- $ref: spi-controller.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: xlnx,versal-ospi-1.0
|
||||
then:
|
||||
required:
|
||||
- power-domains
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
@ -20,6 +28,7 @@ properties:
|
|||
- ti,k2g-qspi
|
||||
- ti,am654-ospi
|
||||
- intel,lgm-qspi
|
||||
- xlnx,versal-ospi-1.0
|
||||
- const: cdns,qspi-nor
|
||||
- const: cdns,qspi-nor
|
||||
|
||||
|
|
@ -65,6 +74,9 @@ properties:
|
|||
data rather than the QSPI clock. Make sure that QSPI return clock
|
||||
is populated on the board before using this property.
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 2
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue