mirror of
https://github.com/torvalds/linux.git
synced 2025-12-07 20:06:24 +00:00
Merge drm/drm-next into drm-xe-next
Backmerging to get up-to-date and to bring in a fix that was merged through drm-misc-fixes. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
This commit is contained in:
Thomas Hellström
16
.mailmap
16
.mailmap
@@ -73,6 +73,8 @@ Andrey Ryabinin <ryabinin.a.a@gmail.com> <aryabinin@virtuozzo.com>
|
|||||||
Andrzej Hajda <andrzej.hajda@intel.com> <a.hajda@samsung.com>
|
Andrzej Hajda <andrzej.hajda@intel.com> <a.hajda@samsung.com>
|
||||||
André Almeida <andrealmeid@igalia.com> <andrealmeid@collabora.com>
|
André Almeida <andrealmeid@igalia.com> <andrealmeid@collabora.com>
|
||||||
Andy Adamson <andros@citi.umich.edu>
|
Andy Adamson <andros@citi.umich.edu>
|
||||||
|
Andy Chiu <andybnac@gmail.com> <andy.chiu@sifive.com>
|
||||||
|
Andy Chiu <andybnac@gmail.com> <taochiu@synology.com>
|
||||||
Andy Shevchenko <andy@kernel.org> <andy@smile.org.ua>
|
Andy Shevchenko <andy@kernel.org> <andy@smile.org.ua>
|
||||||
Andy Shevchenko <andy@kernel.org> <ext-andriy.shevchenko@nokia.com>
|
Andy Shevchenko <andy@kernel.org> <ext-andriy.shevchenko@nokia.com>
|
||||||
Anilkumar Kolli <quic_akolli@quicinc.com> <akolli@codeaurora.org>
|
Anilkumar Kolli <quic_akolli@quicinc.com> <akolli@codeaurora.org>
|
||||||
@@ -197,18 +199,23 @@ Elliot Berman <quic_eberman@quicinc.com> <eberman@codeaurora.org>
|
|||||||
Enric Balletbo i Serra <eballetbo@kernel.org> <enric.balletbo@collabora.com>
|
Enric Balletbo i Serra <eballetbo@kernel.org> <enric.balletbo@collabora.com>
|
||||||
Enric Balletbo i Serra <eballetbo@kernel.org> <eballetbo@iseebcn.com>
|
Enric Balletbo i Serra <eballetbo@kernel.org> <eballetbo@iseebcn.com>
|
||||||
Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>
|
Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>
|
||||||
Eugen Hristev <eugen.hristev@collabora.com> <eugen.hristev@microchip.com>
|
Eugen Hristev <eugen.hristev@linaro.org> <eugen.hristev@microchip.com>
|
||||||
|
Eugen Hristev <eugen.hristev@linaro.org> <eugen.hristev@collabora.com>
|
||||||
Evgeniy Polyakov <johnpol@2ka.mipt.ru>
|
Evgeniy Polyakov <johnpol@2ka.mipt.ru>
|
||||||
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com>
|
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com>
|
||||||
Faith Ekstrand <faith.ekstrand@collabora.com> <jason@jlekstrand.net>
|
Faith Ekstrand <faith.ekstrand@collabora.com> <jason@jlekstrand.net>
|
||||||
Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@intel.com>
|
Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@intel.com>
|
||||||
Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@collabora.com>
|
Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@collabora.com>
|
||||||
|
Fangrui Song <i@maskray.me> <maskray@google.com>
|
||||||
Felipe W Damasio <felipewd@terra.com.br>
|
Felipe W Damasio <felipewd@terra.com.br>
|
||||||
Felix Kuhling <fxkuehl@gmx.de>
|
Felix Kuhling <fxkuehl@gmx.de>
|
||||||
Felix Moeller <felix@derklecks.de>
|
Felix Moeller <felix@derklecks.de>
|
||||||
Fenglin Wu <quic_fenglinw@quicinc.com> <fenglinw@codeaurora.org>
|
Fenglin Wu <quic_fenglinw@quicinc.com> <fenglinw@codeaurora.org>
|
||||||
Filipe Lautert <filipe@icewall.org>
|
Filipe Lautert <filipe@icewall.org>
|
||||||
Finn Thain <fthain@linux-m68k.org> <fthain@telegraphics.com.au>
|
Finn Thain <fthain@linux-m68k.org> <fthain@telegraphics.com.au>
|
||||||
|
Fiona Behrens <me@kloenk.dev>
|
||||||
|
Fiona Behrens <me@kloenk.dev> <me@kloenk.de>
|
||||||
|
Fiona Behrens <me@kloenk.dev> <fin@nyantec.com>
|
||||||
Franck Bui-Huu <vagabon.xyz@gmail.com>
|
Franck Bui-Huu <vagabon.xyz@gmail.com>
|
||||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
|
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
|
||||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sony.com>
|
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sony.com>
|
||||||
@@ -276,7 +283,7 @@ Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.com>
|
|||||||
Jan Kuliga <jtkuliga.kdev@gmail.com> <jankul@alatek.krakow.pl>
|
Jan Kuliga <jtkuliga.kdev@gmail.com> <jankul@alatek.krakow.pl>
|
||||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@linux.intel.com>
|
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@linux.intel.com>
|
||||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko@profian.com>
|
Jarkko Sakkinen <jarkko@kernel.org> <jarkko@profian.com>
|
||||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@tuni.fi>
|
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@parity.io>
|
||||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
|
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
|
||||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
|
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
|
||||||
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
|
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
|
||||||
@@ -300,6 +307,11 @@ Jens Axboe <axboe@kernel.dk> <axboe@fb.com>
|
|||||||
Jens Axboe <axboe@kernel.dk> <axboe@meta.com>
|
Jens Axboe <axboe@kernel.dk> <axboe@meta.com>
|
||||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||||
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
|
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
|
||||||
|
Jesper Dangaard Brouer <hawk@kernel.org> <brouer@redhat.com>
|
||||||
|
Jesper Dangaard Brouer <hawk@kernel.org> <hawk@comx.dk>
|
||||||
|
Jesper Dangaard Brouer <hawk@kernel.org> <jbrouer@redhat.com>
|
||||||
|
Jesper Dangaard Brouer <hawk@kernel.org> <jdb@comx.dk>
|
||||||
|
Jesper Dangaard Brouer <hawk@kernel.org> <netoptimizer@brouer.com>
|
||||||
Jessica Zhang <quic_jesszhan@quicinc.com> <jesszhan@codeaurora.org>
|
Jessica Zhang <quic_jesszhan@quicinc.com> <jesszhan@codeaurora.org>
|
||||||
Jilai Wang <quic_jilaiw@quicinc.com> <jilaiw@codeaurora.org>
|
Jilai Wang <quic_jilaiw@quicinc.com> <jilaiw@codeaurora.org>
|
||||||
Jiri Kosina <jikos@kernel.org> <jikos@jikos.cz>
|
Jiri Kosina <jikos@kernel.org> <jikos@jikos.cz>
|
||||||
|
|||||||
54
CREDITS
54
CREDITS
@@ -1358,10 +1358,6 @@ D: Major kbuild rework during the 2.5 cycle
|
|||||||
D: ISDN Maintainer
|
D: ISDN Maintainer
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
N: Gerrit Renker
|
|
||||||
E: gerrit@erg.abdn.ac.uk
|
|
||||||
D: DCCP protocol support.
|
|
||||||
|
|
||||||
N: Philip Gladstone
|
N: Philip Gladstone
|
||||||
E: philip@gladstonefamily.net
|
E: philip@gladstonefamily.net
|
||||||
D: Kernel / timekeeping stuff
|
D: Kernel / timekeeping stuff
|
||||||
@@ -1677,11 +1673,6 @@ W: http://www.carumba.com/
|
|||||||
D: bug toaster (A1 sauce makes all the difference)
|
D: bug toaster (A1 sauce makes all the difference)
|
||||||
D: Random linux hacker
|
D: Random linux hacker
|
||||||
|
|
||||||
N: James Hogan
|
|
||||||
E: jhogan@kernel.org
|
|
||||||
D: Metag architecture maintainer
|
|
||||||
D: TZ1090 SoC maintainer
|
|
||||||
|
|
||||||
N: Tim Hockin
|
N: Tim Hockin
|
||||||
E: thockin@hockin.org
|
E: thockin@hockin.org
|
||||||
W: http://www.hockin.org/~thockin
|
W: http://www.hockin.org/~thockin
|
||||||
@@ -1697,6 +1688,11 @@ D: hwmon subsystem maintainer
|
|||||||
D: i2c-sis96x and i2c-stub SMBus drivers
|
D: i2c-sis96x and i2c-stub SMBus drivers
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
|
N: James Hogan
|
||||||
|
E: jhogan@kernel.org
|
||||||
|
D: Metag architecture maintainer
|
||||||
|
D: TZ1090 SoC maintainer
|
||||||
|
|
||||||
N: Dirk Hohndel
|
N: Dirk Hohndel
|
||||||
E: hohndel@suse.de
|
E: hohndel@suse.de
|
||||||
D: The XFree86[tm] Project
|
D: The XFree86[tm] Project
|
||||||
@@ -1872,6 +1868,10 @@ S: K osmidomkum 723
|
|||||||
S: 160 00 Praha 6
|
S: 160 00 Praha 6
|
||||||
S: Czech Republic
|
S: Czech Republic
|
||||||
|
|
||||||
|
N: Seth Jennings
|
||||||
|
E: sjenning@redhat.com
|
||||||
|
D: Creation and maintenance of zswap
|
||||||
|
|
||||||
N: Jeremy Kerr
|
N: Jeremy Kerr
|
||||||
D: Maintainer of SPU File System
|
D: Maintainer of SPU File System
|
||||||
|
|
||||||
@@ -2188,19 +2188,6 @@ N: Mike Kravetz
|
|||||||
E: mike.kravetz@oracle.com
|
E: mike.kravetz@oracle.com
|
||||||
D: Maintenance and development of the hugetlb subsystem
|
D: Maintenance and development of the hugetlb subsystem
|
||||||
|
|
||||||
N: Seth Jennings
|
|
||||||
E: sjenning@redhat.com
|
|
||||||
D: Creation and maintenance of zswap
|
|
||||||
|
|
||||||
N: Dan Streetman
|
|
||||||
E: ddstreet@ieee.org
|
|
||||||
D: Maintenance and development of zswap
|
|
||||||
D: Creation and maintenance of the zpool API
|
|
||||||
|
|
||||||
N: Vitaly Wool
|
|
||||||
E: vitaly.wool@konsulko.com
|
|
||||||
D: Maintenance and development of zswap
|
|
||||||
|
|
||||||
N: Andreas S. Krebs
|
N: Andreas S. Krebs
|
||||||
E: akrebs@altavista.net
|
E: akrebs@altavista.net
|
||||||
D: CYPRESS CY82C693 chipset IDE, Digital's PC-Alpha 164SX boards
|
D: CYPRESS CY82C693 chipset IDE, Digital's PC-Alpha 164SX boards
|
||||||
@@ -3191,6 +3178,11 @@ N: Ken Pizzini
|
|||||||
E: ken@halcyon.com
|
E: ken@halcyon.com
|
||||||
D: CDROM driver "sonycd535" (Sony CDU-535/531)
|
D: CDROM driver "sonycd535" (Sony CDU-535/531)
|
||||||
|
|
||||||
|
N: Mathieu Poirier
|
||||||
|
E: mathieu.poirier@linaro.org
|
||||||
|
D: CoreSight kernel subsystem, Maintainer 2014-2022
|
||||||
|
D: Perf tool support for CoreSight
|
||||||
|
|
||||||
N: Stelian Pop
|
N: Stelian Pop
|
||||||
E: stelian@popies.net
|
E: stelian@popies.net
|
||||||
P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
|
P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
|
||||||
@@ -3300,6 +3292,10 @@ S: Schlossbergring 9
|
|||||||
S: 79098 Freiburg
|
S: 79098 Freiburg
|
||||||
S: Germany
|
S: Germany
|
||||||
|
|
||||||
|
N: Gerrit Renker
|
||||||
|
E: gerrit@erg.abdn.ac.uk
|
||||||
|
D: DCCP protocol support.
|
||||||
|
|
||||||
N: Thomas Renninger
|
N: Thomas Renninger
|
||||||
E: trenn@suse.de
|
E: trenn@suse.de
|
||||||
D: cpupowerutils
|
D: cpupowerutils
|
||||||
@@ -3576,11 +3572,6 @@ D: several improvements to system programs
|
|||||||
S: Oldenburg
|
S: Oldenburg
|
||||||
S: Germany
|
S: Germany
|
||||||
|
|
||||||
N: Mathieu Poirier
|
|
||||||
E: mathieu.poirier@linaro.org
|
|
||||||
D: CoreSight kernel subsystem, Maintainer 2014-2022
|
|
||||||
D: Perf tool support for CoreSight
|
|
||||||
|
|
||||||
N: Robert Schwebel
|
N: Robert Schwebel
|
||||||
E: robert@schwebel.de
|
E: robert@schwebel.de
|
||||||
W: https://www.schwebel.de
|
W: https://www.schwebel.de
|
||||||
@@ -3771,6 +3762,11 @@ S: Chr. Winthersvej 1 B, st.th.
|
|||||||
S: DK-1860 Frederiksberg C
|
S: DK-1860 Frederiksberg C
|
||||||
S: Denmark
|
S: Denmark
|
||||||
|
|
||||||
|
N: Dan Streetman
|
||||||
|
E: ddstreet@ieee.org
|
||||||
|
D: Maintenance and development of zswap
|
||||||
|
D: Creation and maintenance of the zpool API
|
||||||
|
|
||||||
N: Drew Sullivan
|
N: Drew Sullivan
|
||||||
E: drew@ss.org
|
E: drew@ss.org
|
||||||
W: http://www.ss.org/
|
W: http://www.ss.org/
|
||||||
@@ -4286,6 +4282,10 @@ S: Pipers Way
|
|||||||
S: Swindon. SN3 1RJ
|
S: Swindon. SN3 1RJ
|
||||||
S: England
|
S: England
|
||||||
|
|
||||||
|
N: Vitaly Wool
|
||||||
|
E: vitaly.wool@konsulko.com
|
||||||
|
D: Maintenance and development of zswap
|
||||||
|
|
||||||
N: Chris Wright
|
N: Chris Wright
|
||||||
E: chrisw@sous-sol.org
|
E: chrisw@sous-sol.org
|
||||||
D: hacking on LSM framework and security modules.
|
D: hacking on LSM framework and security modules.
|
||||||
|
|||||||
@@ -83,3 +83,11 @@ Contact: intel-gfx@lists.freedesktop.org
|
|||||||
Description: RO. Fan speed of device in RPM.
|
Description: RO. Fan speed of device in RPM.
|
||||||
|
|
||||||
Only supported for particular Intel i915 graphics platforms.
|
Only supported for particular Intel i915 graphics platforms.
|
||||||
|
|
||||||
|
What: /sys/bus/pci/drivers/i915/.../hwmon/hwmon<i>/temp1_input
|
||||||
|
Date: November 2024
|
||||||
|
KernelVersion: 6.12
|
||||||
|
Contact: intel-gfx@lists.freedesktop.org
|
||||||
|
Description: RO. GPU package temperature in millidegree Celsius.
|
||||||
|
|
||||||
|
Only supported for particular Intel i915 graphics platforms.
|
||||||
|
|||||||
10
Documentation/ABI/testing/sysfs-driver-panthor-profiling
Normal file
10
Documentation/ABI/testing/sysfs-driver-panthor-profiling
Normal file
@@ -0,0 +1,10 @@
|
|||||||
|
What: /sys/bus/platform/drivers/panthor/.../profiling
|
||||||
|
Date: September 2024
|
||||||
|
KernelVersion: 6.11.0
|
||||||
|
Contact: Adrian Larumbe <adrian.larumbe@collabora.com>
|
||||||
|
Description:
|
||||||
|
Bitmask to enable drm fdinfo's job profiling measurements.
|
||||||
|
Valid values are:
|
||||||
|
0: Don't enable fdinfo job profiling sources.
|
||||||
|
1: Enable GPU cycle measurements for running jobs.
|
||||||
|
2: Enable GPU timestamp sampling for running jobs.
|
||||||
14
Documentation/accel/qaic/aic080.rst
Normal file
14
Documentation/accel/qaic/aic080.rst
Normal file
@@ -0,0 +1,14 @@
|
|||||||
|
.. SPDX-License-Identifier: GPL-2.0-only
|
||||||
|
|
||||||
|
===============================
|
||||||
|
Qualcomm Cloud AI 80 (AIC080)
|
||||||
|
===============================
|
||||||
|
|
||||||
|
Overview
|
||||||
|
========
|
||||||
|
|
||||||
|
The Qualcomm Cloud AI 80/AIC080 family of products are a derivative of AIC100.
|
||||||
|
The number of NSPs and clock rates are reduced to fit within resource
|
||||||
|
constrained solutions. The PCIe Product ID is 0xa080.
|
||||||
|
|
||||||
|
As a derivative product, all AIC100 documentation applies.
|
||||||
@@ -229,6 +229,8 @@ of the defined channels, and their uses.
|
|||||||
| _PERIODIC | | | timestamps in the device side logs with|
|
| _PERIODIC | | | timestamps in the device side logs with|
|
||||||
| | | | the host time source. |
|
| | | | the host time source. |
|
||||||
+----------------+---------+----------+----------------------------------------+
|
+----------------+---------+----------+----------------------------------------+
|
||||||
|
| IPCR | 24 & 25 | AMSS | AF_QIPCRTR clients and servers. |
|
||||||
|
+----------------+---------+----------+----------------------------------------+
|
||||||
|
|
||||||
DMA Bridge
|
DMA Bridge
|
||||||
==========
|
==========
|
||||||
|
|||||||
@@ -10,4 +10,5 @@ accelerator cards.
|
|||||||
.. toctree::
|
.. toctree::
|
||||||
|
|
||||||
qaic
|
qaic
|
||||||
|
aic080
|
||||||
aic100
|
aic100
|
||||||
|
|||||||
@@ -223,7 +223,10 @@ are signed through the PKCS#7 message format to enforce some level of
|
|||||||
authorization of the policies (prohibiting an attacker from gaining
|
authorization of the policies (prohibiting an attacker from gaining
|
||||||
unconstrained root, and deploying an "allow all" policy). These
|
unconstrained root, and deploying an "allow all" policy). These
|
||||||
policies must be signed by a certificate that chains to the
|
policies must be signed by a certificate that chains to the
|
||||||
``SYSTEM_TRUSTED_KEYRING``. With openssl, the policy can be signed by::
|
``SYSTEM_TRUSTED_KEYRING``, or to the secondary and/or platform keyrings if
|
||||||
|
``CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING`` and/or
|
||||||
|
``CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING`` are enabled, respectively.
|
||||||
|
With openssl, the policy can be signed by::
|
||||||
|
|
||||||
openssl smime -sign \
|
openssl smime -sign \
|
||||||
-in "$MY_POLICY" \
|
-in "$MY_POLICY" \
|
||||||
@@ -266,7 +269,7 @@ in the kernel. This file is write-only and accepts a PKCS#7 signed
|
|||||||
policy. Two checks will always be performed on this policy: First, the
|
policy. Two checks will always be performed on this policy: First, the
|
||||||
``policy_names`` must match with the updated version and the existing
|
``policy_names`` must match with the updated version and the existing
|
||||||
version. Second the updated policy must have a policy version greater than
|
version. Second the updated policy must have a policy version greater than
|
||||||
or equal to the currently-running version. This is to prevent rollback attacks.
|
the currently-running version. This is to prevent rollback attacks.
|
||||||
|
|
||||||
The ``delete`` file is used to remove a policy that is no longer needed.
|
The ``delete`` file is used to remove a policy that is no longer needed.
|
||||||
This file is write-only and accepts a value of ``1`` to delete the policy.
|
This file is write-only and accepts a value of ``1`` to delete the policy.
|
||||||
|
|||||||
@@ -425,8 +425,8 @@ This governor exposes only one tunable:
|
|||||||
|
|
||||||
``rate_limit_us``
|
``rate_limit_us``
|
||||||
Minimum time (in microseconds) that has to pass between two consecutive
|
Minimum time (in microseconds) that has to pass between two consecutive
|
||||||
runs of governor computations (default: 1000 times the scaling driver's
|
runs of governor computations (default: 1.5 times the scaling driver's
|
||||||
transition latency).
|
transition latency or the maximum 2ms).
|
||||||
|
|
||||||
The purpose of this tunable is to reduce the scheduler context overhead
|
The purpose of this tunable is to reduce the scheduler context overhead
|
||||||
of the governor which might be excessive without it.
|
of the governor which might be excessive without it.
|
||||||
@@ -474,17 +474,17 @@ This governor exposes the following tunables:
|
|||||||
This is how often the governor's worker routine should run, in
|
This is how often the governor's worker routine should run, in
|
||||||
microseconds.
|
microseconds.
|
||||||
|
|
||||||
Typically, it is set to values of the order of 10000 (10 ms). Its
|
Typically, it is set to values of the order of 2000 (2 ms). Its
|
||||||
default value is equal to the value of ``cpuinfo_transition_latency``
|
default value is to add a 50% breathing room
|
||||||
for each policy this governor is attached to (but since the unit here
|
to ``cpuinfo_transition_latency`` on each policy this governor is
|
||||||
is greater by 1000, this means that the time represented by
|
attached to. The minimum is typically the length of two scheduler
|
||||||
``sampling_rate`` is 1000 times greater than the transition latency by
|
ticks.
|
||||||
default).
|
|
||||||
|
|
||||||
If this tunable is per-policy, the following shell command sets the time
|
If this tunable is per-policy, the following shell command sets the time
|
||||||
represented by it to be 750 times as high as the transition latency::
|
represented by it to be 1.5 times as high as the transition latency
|
||||||
|
(the default)::
|
||||||
|
|
||||||
# echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > ondemand/sampling_rate
|
# echo `$(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate
|
||||||
|
|
||||||
``up_threshold``
|
``up_threshold``
|
||||||
If the estimated CPU load is above this value (in percent), the governor
|
If the estimated CPU load is above this value (in percent), the governor
|
||||||
|
|||||||
@@ -12,7 +12,7 @@ ones.
|
|||||||
|
|
||||||
Of course this is a bad idea to rely on the alignment trap to perform
|
Of course this is a bad idea to rely on the alignment trap to perform
|
||||||
unaligned memory access in general. If those access are predictable, you
|
unaligned memory access in general. If those access are predictable, you
|
||||||
are better to use the macros provided by include/asm/unaligned.h. The
|
are better to use the macros provided by include/linux/unaligned.h. The
|
||||||
alignment trap can fixup misaligned access for the exception cases, but at
|
alignment trap can fixup misaligned access for the exception cases, but at
|
||||||
a high performance cost. It better be rare.
|
a high performance cost. It better be rare.
|
||||||
|
|
||||||
|
|||||||
@@ -146,6 +146,8 @@ stable kernels.
|
|||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
|
| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
|
| ARM | Cortex-A715 | #3456084 | ARM64_ERRATUM_3194386 |
|
||||||
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 |
|
| ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 |
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 |
|
| ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 |
|
||||||
@@ -186,6 +188,8 @@ stable kernels.
|
|||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 |
|
| ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 |
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
|
| ARM | Neoverse-N3 | #3456111 | ARM64_ERRATUM_3194386 |
|
||||||
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| ARM | Neoverse-V1 | #1619801 | N/A |
|
| ARM | Neoverse-V1 | #1619801 | N/A |
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
|
| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
|
||||||
@@ -289,3 +293,5 @@ stable kernels.
|
|||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| Microsoft | Azure Cobalt 100| #2253138 | ARM64_ERRATUM_2253138 |
|
| Microsoft | Azure Cobalt 100| #2253138 | ARM64_ERRATUM_2253138 |
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
|
| Microsoft | Azure Cobalt 100| #3324339 | ARM64_ERRATUM_3194386 |
|
||||||
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
|
|||||||
212
Documentation/core-api/folio_queue.rst
Normal file
212
Documentation/core-api/folio_queue.rst
Normal file
@@ -0,0 +1,212 @@
|
|||||||
|
.. SPDX-License-Identifier: GPL-2.0+
|
||||||
|
|
||||||
|
===========
|
||||||
|
Folio Queue
|
||||||
|
===========
|
||||||
|
|
||||||
|
:Author: David Howells <dhowells@redhat.com>
|
||||||
|
|
||||||
|
.. Contents:
|
||||||
|
|
||||||
|
* Overview
|
||||||
|
* Initialisation
|
||||||
|
* Adding and removing folios
|
||||||
|
* Querying information about a folio
|
||||||
|
* Querying information about a folio_queue
|
||||||
|
* Folio queue iteration
|
||||||
|
* Folio marks
|
||||||
|
* Lockless simultaneous production/consumption issues
|
||||||
|
|
||||||
|
|
||||||
|
Overview
|
||||||
|
========
|
||||||
|
|
||||||
|
The folio_queue struct forms a single segment in a segmented list of folios
|
||||||
|
that can be used to form an I/O buffer. As such, the list can be iterated over
|
||||||
|
using the ITER_FOLIOQ iov_iter type.
|
||||||
|
|
||||||
|
The publicly accessible members of the structure are::
|
||||||
|
|
||||||
|
struct folio_queue {
|
||||||
|
struct folio_queue *next;
|
||||||
|
struct folio_queue *prev;
|
||||||
|
...
|
||||||
|
};
|
||||||
|
|
||||||
|
A pair of pointers are provided, ``next`` and ``prev``, that point to the
|
||||||
|
segments on either side of the segment being accessed. Whilst this is a
|
||||||
|
doubly-linked list, it is intentionally not a circular list; the outward
|
||||||
|
sibling pointers in terminal segments should be NULL.
|
||||||
|
|
||||||
|
Each segment in the list also stores:
|
||||||
|
|
||||||
|
* an ordered sequence of folio pointers,
|
||||||
|
* the size of each folio and
|
||||||
|
* three 1-bit marks per folio,
|
||||||
|
|
||||||
|
but hese should not be accessed directly as the underlying data structure may
|
||||||
|
change, but rather the access functions outlined below should be used.
|
||||||
|
|
||||||
|
The facility can be made accessible by::
|
||||||
|
|
||||||
|
#include <linux/folio_queue.h>
|
||||||
|
|
||||||
|
and to use the iterator::
|
||||||
|
|
||||||
|
#include <linux/uio.h>
|
||||||
|
|
||||||
|
|
||||||
|
Initialisation
|
||||||
|
==============
|
||||||
|
|
||||||
|
A segment should be initialised by calling::
|
||||||
|
|
||||||
|
void folioq_init(struct folio_queue *folioq);
|
||||||
|
|
||||||
|
with a pointer to the segment to be initialised. Note that this will not
|
||||||
|
necessarily initialise all the folio pointers, so care must be taken to check
|
||||||
|
the number of folios added.
|
||||||
|
|
||||||
|
|
||||||
|
Adding and removing folios
|
||||||
|
==========================
|
||||||
|
|
||||||
|
Folios can be set in the next unused slot in a segment struct by calling one
|
||||||
|
of::
|
||||||
|
|
||||||
|
unsigned int folioq_append(struct folio_queue *folioq,
|
||||||
|
struct folio *folio);
|
||||||
|
|
||||||
|
unsigned int folioq_append_mark(struct folio_queue *folioq,
|
||||||
|
struct folio *folio);
|
||||||
|
|
||||||
|
Both functions update the stored folio count, store the folio and note its
|
||||||
|
size. The second function also sets the first mark for the folio added. Both
|
||||||
|
functions return the number of the slot used. [!] Note that no attempt is made
|
||||||
|
to check that the capacity wasn't overrun and the list will not be extended
|
||||||
|
automatically.
|
||||||
|
|
||||||
|
A folio can be excised by calling::
|
||||||
|
|
||||||
|
void folioq_clear(struct folio_queue *folioq, unsigned int slot);
|
||||||
|
|
||||||
|
This clears the slot in the array and also clears all the marks for that folio,
|
||||||
|
but doesn't change the folio count - so future accesses of that slot must check
|
||||||
|
if the slot is occupied.
|
||||||
|
|
||||||
|
|
||||||
|
Querying information about a folio
|
||||||
|
==================================
|
||||||
|
|
||||||
|
Information about the folio in a particular slot may be queried by the
|
||||||
|
following function::
|
||||||
|
|
||||||
|
struct folio *folioq_folio(const struct folio_queue *folioq,
|
||||||
|
unsigned int slot);
|
||||||
|
|
||||||
|
If a folio has not yet been set in that slot, this may yield an undefined
|
||||||
|
pointer. The size of the folio in a slot may be queried with either of::
|
||||||
|
|
||||||
|
unsigned int folioq_folio_order(const struct folio_queue *folioq,
|
||||||
|
unsigned int slot);
|
||||||
|
|
||||||
|
size_t folioq_folio_size(const struct folio_queue *folioq,
|
||||||
|
unsigned int slot);
|
||||||
|
|
||||||
|
The first function returns the size as an order and the second as a number of
|
||||||
|
bytes.
|
||||||
|
|
||||||
|
|
||||||
|
Querying information about a folio_queue
|
||||||
|
========================================
|
||||||
|
|
||||||
|
Information may be retrieved about a particular segment with the following
|
||||||
|
functions::
|
||||||
|
|
||||||
|
unsigned int folioq_nr_slots(const struct folio_queue *folioq);
|
||||||
|
|
||||||
|
unsigned int folioq_count(struct folio_queue *folioq);
|
||||||
|
|
||||||
|
bool folioq_full(struct folio_queue *folioq);
|
||||||
|
|
||||||
|
The first function returns the maximum capacity of a segment. It must not be
|
||||||
|
assumed that this won't vary between segments. The second returns the number
|
||||||
|
of folios added to a segments and the third is a shorthand to indicate if the
|
||||||
|
segment has been filled to capacity.
|
||||||
|
|
||||||
|
Not that the count and fullness are not affected by clearing folios from the
|
||||||
|
segment. These are more about indicating how many slots in the array have been
|
||||||
|
initialised, and it assumed that slots won't get reused, but rather the segment
|
||||||
|
will get discarded as the queue is consumed.
|
||||||
|
|
||||||
|
|
||||||
|
Folio marks
|
||||||
|
===========
|
||||||
|
|
||||||
|
Folios within a queue can also have marks assigned to them. These marks can be
|
||||||
|
used to note information such as if a folio needs folio_put() calling upon it.
|
||||||
|
There are three marks available to be set for each folio.
|
||||||
|
|
||||||
|
The marks can be set by::
|
||||||
|
|
||||||
|
void folioq_mark(struct folio_queue *folioq, unsigned int slot);
|
||||||
|
void folioq_mark2(struct folio_queue *folioq, unsigned int slot);
|
||||||
|
void folioq_mark3(struct folio_queue *folioq, unsigned int slot);
|
||||||
|
|
||||||
|
Cleared by::
|
||||||
|
|
||||||
|
void folioq_unmark(struct folio_queue *folioq, unsigned int slot);
|
||||||
|
void folioq_unmark2(struct folio_queue *folioq, unsigned int slot);
|
||||||
|
void folioq_unmark3(struct folio_queue *folioq, unsigned int slot);
|
||||||
|
|
||||||
|
And the marks can be queried by::
|
||||||
|
|
||||||
|
bool folioq_is_marked(const struct folio_queue *folioq, unsigned int slot);
|
||||||
|
bool folioq_is_marked2(const struct folio_queue *folioq, unsigned int slot);
|
||||||
|
bool folioq_is_marked3(const struct folio_queue *folioq, unsigned int slot);
|
||||||
|
|
||||||
|
The marks can be used for any purpose and are not interpreted by this API.
|
||||||
|
|
||||||
|
|
||||||
|
Folio queue iteration
|
||||||
|
=====================
|
||||||
|
|
||||||
|
A list of segments may be iterated over using the I/O iterator facility using
|
||||||
|
an ``iov_iter`` iterator of ``ITER_FOLIOQ`` type. The iterator may be
|
||||||
|
initialised with::
|
||||||
|
|
||||||
|
void iov_iter_folio_queue(struct iov_iter *i, unsigned int direction,
|
||||||
|
const struct folio_queue *folioq,
|
||||||
|
unsigned int first_slot, unsigned int offset,
|
||||||
|
size_t count);
|
||||||
|
|
||||||
|
This may be told to start at a particular segment, slot and offset within a
|
||||||
|
queue. The iov iterator functions will follow the next pointers when advancing
|
||||||
|
and prev pointers when reverting when needed.
|
||||||
|
|
||||||
|
|
||||||
|
Lockless simultaneous production/consumption issues
|
||||||
|
===================================================
|
||||||
|
|
||||||
|
If properly managed, the list can be extended by the producer at the head end
|
||||||
|
and shortened by the consumer at the tail end simultaneously without the need
|
||||||
|
to take locks. The ITER_FOLIOQ iterator inserts appropriate barriers to aid
|
||||||
|
with this.
|
||||||
|
|
||||||
|
Care must be taken when simultaneously producing and consuming a list. If the
|
||||||
|
last segment is reached and the folios it refers to are entirely consumed by
|
||||||
|
the IOV iterators, an iov_iter struct will be left pointing to the last segment
|
||||||
|
with a slot number equal to the capacity of that segment. The iterator will
|
||||||
|
try to continue on from this if there's another segment available when it is
|
||||||
|
used again, but care must be taken lest the segment got removed and freed by
|
||||||
|
the consumer before the iterator was advanced.
|
||||||
|
|
||||||
|
It is recommended that the queue always contain at least one segment, even if
|
||||||
|
that segment has never been filled or is entirely spent. This prevents the
|
||||||
|
head and tail pointers from collapsing.
|
||||||
|
|
||||||
|
|
||||||
|
API Function Reference
|
||||||
|
======================
|
||||||
|
|
||||||
|
.. kernel-doc:: include/linux/folio_queue.h
|
||||||
@@ -37,6 +37,7 @@ Library functionality that is used throughout the kernel.
|
|||||||
kref
|
kref
|
||||||
cleanup
|
cleanup
|
||||||
assoc_array
|
assoc_array
|
||||||
|
folio_queue
|
||||||
xarray
|
xarray
|
||||||
maple_tree
|
maple_tree
|
||||||
idr
|
idr
|
||||||
|
|||||||
@@ -12,7 +12,10 @@ Pkeys Userspace (PKU) is a feature which can be found on:
|
|||||||
* Intel server CPUs, Skylake and later
|
* Intel server CPUs, Skylake and later
|
||||||
* Intel client CPUs, Tiger Lake (11th Gen Core) and later
|
* Intel client CPUs, Tiger Lake (11th Gen Core) and later
|
||||||
* Future AMD CPUs
|
* Future AMD CPUs
|
||||||
|
* arm64 CPUs implementing the Permission Overlay Extension (FEAT_S1POE)
|
||||||
|
|
||||||
|
x86_64
|
||||||
|
======
|
||||||
Pkeys work by dedicating 4 previously Reserved bits in each page table entry to
|
Pkeys work by dedicating 4 previously Reserved bits in each page table entry to
|
||||||
a "protection key", giving 16 possible keys.
|
a "protection key", giving 16 possible keys.
|
||||||
|
|
||||||
@@ -28,6 +31,22 @@ register. The feature is only available in 64-bit mode, even though there is
|
|||||||
theoretically space in the PAE PTEs. These permissions are enforced on data
|
theoretically space in the PAE PTEs. These permissions are enforced on data
|
||||||
access only and have no effect on instruction fetches.
|
access only and have no effect on instruction fetches.
|
||||||
|
|
||||||
|
arm64
|
||||||
|
=====
|
||||||
|
|
||||||
|
Pkeys use 3 bits in each page table entry, to encode a "protection key index",
|
||||||
|
giving 8 possible keys.
|
||||||
|
|
||||||
|
Protections for each key are defined with a per-CPU user-writable system
|
||||||
|
register (POR_EL0). This is a 64-bit register encoding read, write and execute
|
||||||
|
overlay permissions for each protection key index.
|
||||||
|
|
||||||
|
Being a CPU register, POR_EL0 is inherently thread-local, potentially giving
|
||||||
|
each thread a different set of protections from every other thread.
|
||||||
|
|
||||||
|
Unlike x86_64, the protection key permissions also apply to instruction
|
||||||
|
fetches.
|
||||||
|
|
||||||
Syscalls
|
Syscalls
|
||||||
========
|
========
|
||||||
|
|
||||||
@@ -38,11 +57,10 @@ There are 3 system calls which directly interact with pkeys::
|
|||||||
int pkey_mprotect(unsigned long start, size_t len,
|
int pkey_mprotect(unsigned long start, size_t len,
|
||||||
unsigned long prot, int pkey);
|
unsigned long prot, int pkey);
|
||||||
|
|
||||||
Before a pkey can be used, it must first be allocated with
|
Before a pkey can be used, it must first be allocated with pkey_alloc(). An
|
||||||
pkey_alloc(). An application calls the WRPKRU instruction
|
application writes to the architecture specific CPU register directly in order
|
||||||
directly in order to change access permissions to memory covered
|
to change access permissions to memory covered with a key. In this example
|
||||||
with a key. In this example WRPKRU is wrapped by a C function
|
this is wrapped by a C function called pkey_set().
|
||||||
called pkey_set().
|
|
||||||
::
|
::
|
||||||
|
|
||||||
int real_prot = PROT_READ|PROT_WRITE;
|
int real_prot = PROT_READ|PROT_WRITE;
|
||||||
@@ -64,9 +82,9 @@ is no longer in use::
|
|||||||
munmap(ptr, PAGE_SIZE);
|
munmap(ptr, PAGE_SIZE);
|
||||||
pkey_free(pkey);
|
pkey_free(pkey);
|
||||||
|
|
||||||
.. note:: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions.
|
.. note:: pkey_set() is a wrapper around writing to the CPU register.
|
||||||
An example implementation can be found in
|
Example implementations can be found in
|
||||||
tools/testing/selftests/x86/protection_keys.c.
|
tools/testing/selftests/mm/pkey-{arm64,powerpc,x86}.h
|
||||||
|
|
||||||
Behavior
|
Behavior
|
||||||
========
|
========
|
||||||
@@ -96,3 +114,7 @@ with a read()::
|
|||||||
The kernel will send a SIGSEGV in both cases, but si_code will be set
|
The kernel will send a SIGSEGV in both cases, but si_code will be set
|
||||||
to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when
|
to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when
|
||||||
the plain mprotect() permissions are violated.
|
the plain mprotect() permissions are violated.
|
||||||
|
|
||||||
|
Note that kernel accesses from a kthread (such as io_uring) will use a default
|
||||||
|
value for the protection key register and so will not be consistent with
|
||||||
|
userspace's value of the register or mprotect().
|
||||||
|
|||||||
@@ -203,7 +203,7 @@ Avoiding unaligned accesses
|
|||||||
===========================
|
===========================
|
||||||
|
|
||||||
The easiest way to avoid unaligned access is to use the get_unaligned() and
|
The easiest way to avoid unaligned access is to use the get_unaligned() and
|
||||||
put_unaligned() macros provided by the <asm/unaligned.h> header file.
|
put_unaligned() macros provided by the <linux/unaligned.h> header file.
|
||||||
|
|
||||||
Going back to an earlier example of code that potentially causes unaligned
|
Going back to an earlier example of code that potentially causes unaligned
|
||||||
access::
|
access::
|
||||||
|
|||||||
@@ -81,9 +81,22 @@ properties:
|
|||||||
|
|
||||||
properties:
|
properties:
|
||||||
port@0:
|
port@0:
|
||||||
$ref: /schemas/graph.yaml#/properties/port
|
unevaluatedProperties: false
|
||||||
|
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||||
description: Parallel RGB input port
|
description: Parallel RGB input port
|
||||||
|
|
||||||
|
properties:
|
||||||
|
endpoint:
|
||||||
|
$ref: /schemas/graph.yaml#/$defs/endpoint-base
|
||||||
|
unevaluatedProperties: false
|
||||||
|
|
||||||
|
properties:
|
||||||
|
bus-width:
|
||||||
|
description:
|
||||||
|
Endpoint bus width.
|
||||||
|
enum: [ 16, 18, 24 ]
|
||||||
|
default: 24
|
||||||
|
|
||||||
port@1:
|
port@1:
|
||||||
$ref: /schemas/graph.yaml#/properties/port
|
$ref: /schemas/graph.yaml#/properties/port
|
||||||
description: HDMI output port
|
description: HDMI output port
|
||||||
|
|||||||
@@ -0,0 +1,57 @@
|
|||||||
|
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/display/bridge/ti,tdp158.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: TI TDP158 HDMI to TMDS Redriver
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Arnaud Vrac <avrac@freebox.fr>
|
||||||
|
- Pierre-Hugues Husson <phhusson@freebox.fr>
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
const: ti,tdp158
|
||||||
|
|
||||||
|
# The reg property is required if and only if the device is connected
|
||||||
|
# to an I2C bus. In pin strap mode, reg must not be specified.
|
||||||
|
reg:
|
||||||
|
description: I2C address of the device
|
||||||
|
|
||||||
|
# Pin 36 = Operation Enable / Reset Pin
|
||||||
|
# OE = L: Power Down Mode
|
||||||
|
# OE = H: Normal Operation
|
||||||
|
# Internal weak pullup - device resets on H to L transitions
|
||||||
|
enable-gpios:
|
||||||
|
description: GPIO controlling bridge enable
|
||||||
|
|
||||||
|
vcc-supply:
|
||||||
|
description: Power supply 3.3V
|
||||||
|
|
||||||
|
vdd-supply:
|
||||||
|
description: Power supply 1.1V
|
||||||
|
|
||||||
|
ports:
|
||||||
|
$ref: /schemas/graph.yaml#/properties/ports
|
||||||
|
|
||||||
|
properties:
|
||||||
|
port@0:
|
||||||
|
$ref: /schemas/graph.yaml#/properties/port
|
||||||
|
description: Bridge input
|
||||||
|
|
||||||
|
port@1:
|
||||||
|
$ref: /schemas/graph.yaml#/properties/port
|
||||||
|
description: Bridge output
|
||||||
|
|
||||||
|
required:
|
||||||
|
- port@0
|
||||||
|
- port@1
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- vcc-supply
|
||||||
|
- vdd-supply
|
||||||
|
- ports
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
@@ -60,6 +60,10 @@ properties:
|
|||||||
data-lines:
|
data-lines:
|
||||||
$ref: /schemas/types.yaml#/definitions/uint32
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
enum: [ 16, 18, 24 ]
|
enum: [ 16, 18, 24 ]
|
||||||
|
deprecated: true
|
||||||
|
|
||||||
|
bus-width:
|
||||||
|
enum: [ 16, 18, 24 ]
|
||||||
|
|
||||||
port@1:
|
port@1:
|
||||||
$ref: /schemas/graph.yaml#/properties/port
|
$ref: /schemas/graph.yaml#/properties/port
|
||||||
|
|||||||
@@ -0,0 +1,54 @@
|
|||||||
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/display/elgin,jg10309-01.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: Elgin JG10309-01 SPI-controlled display
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Fabio Estevam <festevam@gmail.com>
|
||||||
|
|
||||||
|
description: |
|
||||||
|
The Elgin JG10309-01 SPI-controlled display is used on the RV1108-Elgin-r1
|
||||||
|
board and is a custom display.
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
const: elgin,jg10309-01
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
spi-max-frequency:
|
||||||
|
maximum: 24000000
|
||||||
|
|
||||||
|
spi-cpha: true
|
||||||
|
|
||||||
|
spi-cpol: true
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
- spi-cpha
|
||||||
|
- spi-cpol
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
spi {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
display@0 {
|
||||||
|
compatible = "elgin,jg10309-01";
|
||||||
|
reg = <0>;
|
||||||
|
spi-max-frequency = <24000000>;
|
||||||
|
spi-cpha;
|
||||||
|
spi-cpol;
|
||||||
|
};
|
||||||
|
};
|
||||||
@@ -119,7 +119,6 @@ Optional properties:
|
|||||||
- interface-pix-fmt: How this display is connected to the
|
- interface-pix-fmt: How this display is connected to the
|
||||||
display interface. Currently supported types: "rgb24", "rgb565", "bgr666"
|
display interface. Currently supported types: "rgb24", "rgb565", "bgr666"
|
||||||
and "lvds666".
|
and "lvds666".
|
||||||
- edid: verbatim EDID data block describing attached display.
|
|
||||||
- ddc: phandle describing the i2c bus handling the display data
|
- ddc: phandle describing the i2c bus handling the display data
|
||||||
channel
|
channel
|
||||||
- port@[0-1]: Port nodes with endpoint definitions as defined in
|
- port@[0-1]: Port nodes with endpoint definitions as defined in
|
||||||
@@ -131,7 +130,6 @@ example:
|
|||||||
|
|
||||||
disp0 {
|
disp0 {
|
||||||
compatible = "fsl,imx-parallel-display";
|
compatible = "fsl,imx-parallel-display";
|
||||||
edid = [edid-data];
|
|
||||||
interface-pix-fmt = "rgb24";
|
interface-pix-fmt = "rgb24";
|
||||||
|
|
||||||
port@0 {
|
port@0 {
|
||||||
|
|||||||
@@ -62,7 +62,6 @@ Required properties:
|
|||||||
display-timings are used instead.
|
display-timings are used instead.
|
||||||
|
|
||||||
Optional properties (required if display-timings are used):
|
Optional properties (required if display-timings are used):
|
||||||
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
|
|
||||||
- display-timings : A node that describes the display timings as defined in
|
- display-timings : A node that describes the display timings as defined in
|
||||||
Documentation/devicetree/bindings/display/panel/display-timing.txt.
|
Documentation/devicetree/bindings/display/panel/display-timing.txt.
|
||||||
- fsl,data-mapping : should be "spwg" or "jeida"
|
- fsl,data-mapping : should be "spwg" or "jeida"
|
||||||
|
|||||||
@@ -63,6 +63,16 @@ properties:
|
|||||||
- const: sleep
|
- const: sleep
|
||||||
|
|
||||||
power-domains:
|
power-domains:
|
||||||
|
description: |
|
||||||
|
The MediaTek DPI module is typically associated with one of the
|
||||||
|
following multimedia power domains:
|
||||||
|
POWER_DOMAIN_DISPLAY
|
||||||
|
POWER_DOMAIN_VDOSYS
|
||||||
|
POWER_DOMAIN_MM
|
||||||
|
The specific power domain used varies depending on the SoC design.
|
||||||
|
|
||||||
|
It is recommended to explicitly add the appropriate power domain
|
||||||
|
property to the DPI node in the device tree.
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
||||||
port:
|
port:
|
||||||
@@ -79,20 +89,6 @@ required:
|
|||||||
- clock-names
|
- clock-names
|
||||||
- port
|
- port
|
||||||
|
|
||||||
allOf:
|
|
||||||
- if:
|
|
||||||
not:
|
|
||||||
properties:
|
|
||||||
compatible:
|
|
||||||
contains:
|
|
||||||
enum:
|
|
||||||
- mediatek,mt6795-dpi
|
|
||||||
- mediatek,mt8173-dpi
|
|
||||||
- mediatek,mt8186-dpi
|
|
||||||
then:
|
|
||||||
properties:
|
|
||||||
power-domains: false
|
|
||||||
|
|
||||||
additionalProperties: false
|
additionalProperties: false
|
||||||
|
|
||||||
examples:
|
examples:
|
||||||
|
|||||||
@@ -38,6 +38,7 @@ properties:
|
|||||||
description: A phandle and PM domain specifier as defined by bindings of
|
description: A phandle and PM domain specifier as defined by bindings of
|
||||||
the power controller specified by phandle. See
|
the power controller specified by phandle. See
|
||||||
Documentation/devicetree/bindings/power/power-domain.yaml for details.
|
Documentation/devicetree/bindings/power/power-domain.yaml for details.
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
mediatek,gce-client-reg:
|
mediatek,gce-client-reg:
|
||||||
description:
|
description:
|
||||||
@@ -57,6 +58,9 @@ properties:
|
|||||||
clocks:
|
clocks:
|
||||||
items:
|
items:
|
||||||
- description: SPLIT Clock
|
- description: SPLIT Clock
|
||||||
|
- description: Used for interfacing with the HDMI RX signal source.
|
||||||
|
- description: Paired with receiving HDMI RX metadata.
|
||||||
|
minItems: 1
|
||||||
|
|
||||||
required:
|
required:
|
||||||
- compatible
|
- compatible
|
||||||
@@ -72,9 +76,24 @@ allOf:
|
|||||||
const: mediatek,mt8195-mdp3-split
|
const: mediatek,mt8195-mdp3-split
|
||||||
|
|
||||||
then:
|
then:
|
||||||
|
properties:
|
||||||
|
clocks:
|
||||||
|
minItems: 3
|
||||||
|
|
||||||
required:
|
required:
|
||||||
- mediatek,gce-client-reg
|
- mediatek,gce-client-reg
|
||||||
|
|
||||||
|
- if:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
contains:
|
||||||
|
const: mediatek,mt8173-disp-split
|
||||||
|
|
||||||
|
then:
|
||||||
|
properties:
|
||||||
|
clocks:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
additionalProperties: false
|
additionalProperties: false
|
||||||
|
|
||||||
examples:
|
examples:
|
||||||
|
|||||||
@@ -51,6 +51,14 @@ properties:
|
|||||||
$ref: /schemas/types.yaml#/definitions/uint32
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
enum: [0, 90, 180, 270]
|
enum: [0, 90, 180, 270]
|
||||||
|
|
||||||
|
flip-horizontal:
|
||||||
|
description: boolean to flip image horizontally
|
||||||
|
type: boolean
|
||||||
|
|
||||||
|
flip-vertical:
|
||||||
|
description: boolean to flip image vertically
|
||||||
|
type: boolean
|
||||||
|
|
||||||
# Display Timings
|
# Display Timings
|
||||||
panel-timing:
|
panel-timing:
|
||||||
description:
|
description:
|
||||||
|
|||||||
@@ -50,6 +50,8 @@ properties:
|
|||||||
- hannstar,hsd101pww2
|
- hannstar,hsd101pww2
|
||||||
# Hydis Technologies 7" WXGA (800x1280) TFT LCD LVDS panel
|
# Hydis Technologies 7" WXGA (800x1280) TFT LCD LVDS panel
|
||||||
- hydis,hv070wx2-1e0
|
- hydis,hv070wx2-1e0
|
||||||
|
# Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
|
||||||
|
- jenson,bl-jt60050-01a
|
||||||
- tbs,a711-panel
|
- tbs,a711-panel
|
||||||
|
|
||||||
- const: panel-lvds
|
- const: panel-lvds
|
||||||
|
|||||||
@@ -200,6 +200,8 @@ properties:
|
|||||||
- logictechno,lttd800480070-l2rt
|
- logictechno,lttd800480070-l2rt
|
||||||
# Logic Technologies LTTD800480070-L6WH-RT 7” 800x480 TFT Resistive Touch Module
|
# Logic Technologies LTTD800480070-L6WH-RT 7” 800x480 TFT Resistive Touch Module
|
||||||
- logictechno,lttd800480070-l6wh-rt
|
- logictechno,lttd800480070-l6wh-rt
|
||||||
|
# Microchip AC69T88A 5" 800X480 LVDS interface TFT LCD Panel
|
||||||
|
- microchip,ac69t88a
|
||||||
# Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel
|
# Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel
|
||||||
- mitsubishi,aa070mc01-ca1
|
- mitsubishi,aa070mc01-ca1
|
||||||
# Mitsubishi AA084XE01 8.4" XGA TFT LCD panel
|
# Mitsubishi AA084XE01 8.4" XGA TFT LCD panel
|
||||||
|
|||||||
@@ -0,0 +1,79 @@
|
|||||||
|
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/display/panel/samsung,ams581vf01.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: Samsung AMS581VF01 SOFEF01-based 5.81" 1080x2340 MIPI-DSI Panel
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Danila Tikhonov <danila@jiaxyga.com>
|
||||||
|
|
||||||
|
description:
|
||||||
|
The Samsung AMS581VF01 is a 5.81 inch 1080x2340 MIPI-DSI CMD mode OLED panel.
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- $ref: panel-common.yaml#
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
const: samsung,ams581vf01
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
vdd3p3-supply:
|
||||||
|
description: 3.3V source voltage rail
|
||||||
|
|
||||||
|
vddio-supply:
|
||||||
|
description: I/O source voltage rail
|
||||||
|
|
||||||
|
vsn-supply:
|
||||||
|
description: Negative source voltage rail
|
||||||
|
|
||||||
|
vsp-supply:
|
||||||
|
description: Positive source voltage rail
|
||||||
|
|
||||||
|
reset-gpios: true
|
||||||
|
port: true
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
- vdd3p3-supply
|
||||||
|
- vddio-supply
|
||||||
|
- vsn-supply
|
||||||
|
- vsp-supply
|
||||||
|
- reset-gpios
|
||||||
|
- port
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
#include <dt-bindings/gpio/gpio.h>
|
||||||
|
|
||||||
|
dsi {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
panel@0 {
|
||||||
|
compatible = "samsung,ams581vf01";
|
||||||
|
reg = <0>;
|
||||||
|
|
||||||
|
vdd3p3-supply = <&vreg_l7c_3p0>;
|
||||||
|
vddio-supply = <&vreg_l13a_1p8>;
|
||||||
|
vsn-supply = <&vreg_ibb>;
|
||||||
|
vsp-supply = <&vreg_lab>;
|
||||||
|
|
||||||
|
reset-gpios = <&pm6150l_gpios 9 GPIO_ACTIVE_LOW>;
|
||||||
|
|
||||||
|
port {
|
||||||
|
panel_in: endpoint {
|
||||||
|
remote-endpoint = <&mdss_dsi0_out>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
...
|
||||||
@@ -0,0 +1,80 @@
|
|||||||
|
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/display/panel/samsung,ams639rq08.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: Samsung AMS639RQ08 EA8076-based 6.39" 1080x2340 MIPI-DSI Panel
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Danila Tikhonov <danila@jiaxyga.com>
|
||||||
|
- Jens Reidel <adrian@travitia.xyz>
|
||||||
|
|
||||||
|
description:
|
||||||
|
The Samsung AMS639RQ08 is a 6.39 inch 1080x2340 MIPI-DSI CMD mode AMOLED panel.
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- $ref: panel-common.yaml#
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
const: samsung,ams639rq08
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
vdd3p3-supply:
|
||||||
|
description: 3.3V source voltage rail
|
||||||
|
|
||||||
|
vddio-supply:
|
||||||
|
description: I/O source voltage rail
|
||||||
|
|
||||||
|
vsn-supply:
|
||||||
|
description: Negative source voltage rail
|
||||||
|
|
||||||
|
vsp-supply:
|
||||||
|
description: Positive source voltage rail
|
||||||
|
|
||||||
|
reset-gpios: true
|
||||||
|
port: true
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
- vdd3p3-supply
|
||||||
|
- vddio-supply
|
||||||
|
- vsn-supply
|
||||||
|
- vsp-supply
|
||||||
|
- reset-gpios
|
||||||
|
- port
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
#include <dt-bindings/gpio/gpio.h>
|
||||||
|
|
||||||
|
dsi {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
panel@0 {
|
||||||
|
compatible = "samsung,ams639rq08";
|
||||||
|
reg = <0>;
|
||||||
|
|
||||||
|
vdd3p3-supply = <&vreg_l18a_2p8>;
|
||||||
|
vddio-supply = <&vreg_l13a_1p8>;
|
||||||
|
vsn-supply = <&vreg_ibb>;
|
||||||
|
vsp-supply = <&vreg_lab>;
|
||||||
|
|
||||||
|
reset-gpios = <&pm6150l_gpios 9 GPIO_ACTIVE_LOW>;
|
||||||
|
|
||||||
|
port {
|
||||||
|
panel_in: endpoint {
|
||||||
|
remote-endpoint = <&mdss_dsi0_out>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
...
|
||||||
@@ -0,0 +1,75 @@
|
|||||||
|
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/display/panel/samsung,s6e3ha8.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: Samsung s6e3ha8 AMOLED DSI panel
|
||||||
|
|
||||||
|
description: The s6e3ha8 is a 1440x2960 DPI display panel from Samsung Mobile
|
||||||
|
Displays (SMD).
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Dzmitry Sankouski <dsankouski@gmail.com>
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- $ref: panel-common.yaml#
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
const: samsung,s6e3ha8
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
reset-gpios: true
|
||||||
|
|
||||||
|
port: true
|
||||||
|
|
||||||
|
vdd3-supply:
|
||||||
|
description: VDD regulator
|
||||||
|
|
||||||
|
vci-supply:
|
||||||
|
description: VCI regulator
|
||||||
|
|
||||||
|
vddr-supply:
|
||||||
|
description: VDDR regulator
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reset-gpios
|
||||||
|
- vdd3-supply
|
||||||
|
- vci-supply
|
||||||
|
- vddr-supply
|
||||||
|
|
||||||
|
unevaluatedProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
#include <dt-bindings/gpio/gpio.h>
|
||||||
|
|
||||||
|
dsi {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
panel@0 {
|
||||||
|
compatible = "samsung,s6e3ha8";
|
||||||
|
reg = <0>;
|
||||||
|
vci-supply = <&s2dos05_ldo4>;
|
||||||
|
vddr-supply = <&s2dos05_buck1>;
|
||||||
|
vdd3-supply = <&s2dos05_ldo1>;
|
||||||
|
te-gpios = <&tlmm 10 GPIO_ACTIVE_HIGH>;
|
||||||
|
reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
|
||||||
|
pinctrl-0 = <&sde_dsi_active &sde_te_active_sleep>;
|
||||||
|
pinctrl-1 = <&sde_dsi_suspend &sde_te_active_sleep>;
|
||||||
|
pinctrl-names = "default", "sleep";
|
||||||
|
|
||||||
|
port {
|
||||||
|
panel_in: endpoint {
|
||||||
|
remote-endpoint = <&mdss_dsi0_out>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
...
|
||||||
@@ -0,0 +1,65 @@
|
|||||||
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/display/panel/samsung,s6e88a0-ams427ap24.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: Samsung AMS427AP24 panel with S6E88A0 controller
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Jakob Hauser <jahau@rocketmail.com>
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- $ref: panel-common.yaml#
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
const: samsung,s6e88a0-ams427ap24
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
port: true
|
||||||
|
reset-gpios: true
|
||||||
|
flip-horizontal: true
|
||||||
|
|
||||||
|
vdd3-supply:
|
||||||
|
description: core voltage supply
|
||||||
|
|
||||||
|
vci-supply:
|
||||||
|
description: voltage supply for analog circuits
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
- port
|
||||||
|
- reset-gpios
|
||||||
|
- vdd3-supply
|
||||||
|
- vci-supply
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
#include <dt-bindings/gpio/gpio.h>
|
||||||
|
|
||||||
|
dsi {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
panel@0 {
|
||||||
|
compatible = "samsung,s6e88a0-ams427ap24";
|
||||||
|
reg = <0>;
|
||||||
|
|
||||||
|
vdd3-supply = <&pm8916_l17>;
|
||||||
|
vci-supply = <&pm8916_l6>;
|
||||||
|
reset-gpios = <&tlmm 25 GPIO_ACTIVE_LOW>;
|
||||||
|
flip-horizontal;
|
||||||
|
|
||||||
|
port {
|
||||||
|
panel_in: endpoint {
|
||||||
|
remote-endpoint = <&mdss_dsi0_out>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
@@ -21,6 +21,8 @@ properties:
|
|||||||
|
|
||||||
reset-gpios: true
|
reset-gpios: true
|
||||||
display-timings: true
|
display-timings: true
|
||||||
|
flip-horizontal: true
|
||||||
|
flip-vertical: true
|
||||||
|
|
||||||
vdd3-supply:
|
vdd3-supply:
|
||||||
description: core voltage supply
|
description: core voltage supply
|
||||||
@@ -46,14 +48,6 @@ properties:
|
|||||||
panel-height-mm:
|
panel-height-mm:
|
||||||
description: physical panel height [mm]
|
description: physical panel height [mm]
|
||||||
|
|
||||||
flip-horizontal:
|
|
||||||
description: boolean to flip image horizontally
|
|
||||||
type: boolean
|
|
||||||
|
|
||||||
flip-vertical:
|
|
||||||
description: boolean to flip image vertically
|
|
||||||
type: boolean
|
|
||||||
|
|
||||||
required:
|
required:
|
||||||
- compatible
|
- compatible
|
||||||
- reg
|
- reg
|
||||||
|
|||||||
@@ -0,0 +1,188 @@
|
|||||||
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: Rockchip DW HDMI QP TX Encoder
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
|
||||||
|
|
||||||
|
description: |
|
||||||
|
Rockchip RK3588 SoC integrates the Synopsys DesignWare HDMI QP TX controller
|
||||||
|
IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block, providing the
|
||||||
|
following features, among others:
|
||||||
|
|
||||||
|
* Fixed Rate Link (FRL)
|
||||||
|
* Display Stream Compression (DSC)
|
||||||
|
* 4K@120Hz and 8K@60Hz video modes
|
||||||
|
* Variable Refresh Rate (VRR) including Quick Media Switching (QMS)
|
||||||
|
* Fast Vactive (FVA)
|
||||||
|
* SCDC I2C DDC access
|
||||||
|
* Multi-stream audio
|
||||||
|
* Enhanced Audio Return Channel (EARC)
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- $ref: /schemas/sound/dai-common.yaml#
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
enum:
|
||||||
|
- rockchip,rk3588-dw-hdmi-qp
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
clocks:
|
||||||
|
items:
|
||||||
|
- description: Peripheral/APB bus clock
|
||||||
|
- description: EARC RX biphase clock
|
||||||
|
- description: Reference clock
|
||||||
|
- description: Audio interface clock
|
||||||
|
- description: TMDS/FRL link clock
|
||||||
|
- description: Video datapath clock
|
||||||
|
|
||||||
|
clock-names:
|
||||||
|
items:
|
||||||
|
- const: pclk
|
||||||
|
- const: earc
|
||||||
|
- const: ref
|
||||||
|
- const: aud
|
||||||
|
- const: hdp
|
||||||
|
- const: hclk_vo1
|
||||||
|
|
||||||
|
interrupts:
|
||||||
|
items:
|
||||||
|
- description: AVP Unit interrupt
|
||||||
|
- description: CEC interrupt
|
||||||
|
- description: eARC RX interrupt
|
||||||
|
- description: Main Unit interrupt
|
||||||
|
- description: HPD interrupt
|
||||||
|
|
||||||
|
interrupt-names:
|
||||||
|
items:
|
||||||
|
- const: avp
|
||||||
|
- const: cec
|
||||||
|
- const: earc
|
||||||
|
- const: main
|
||||||
|
- const: hpd
|
||||||
|
|
||||||
|
phys:
|
||||||
|
maxItems: 1
|
||||||
|
description: The HDMI/eDP PHY
|
||||||
|
|
||||||
|
ports:
|
||||||
|
$ref: /schemas/graph.yaml#/properties/ports
|
||||||
|
|
||||||
|
properties:
|
||||||
|
port@0:
|
||||||
|
$ref: /schemas/graph.yaml#/properties/port
|
||||||
|
description: Video port for RGB/YUV input.
|
||||||
|
|
||||||
|
port@1:
|
||||||
|
$ref: /schemas/graph.yaml#/properties/port
|
||||||
|
description: Video port for HDMI/eDP output.
|
||||||
|
|
||||||
|
required:
|
||||||
|
- port@0
|
||||||
|
- port@1
|
||||||
|
|
||||||
|
power-domains:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
resets:
|
||||||
|
maxItems: 2
|
||||||
|
|
||||||
|
reset-names:
|
||||||
|
items:
|
||||||
|
- const: ref
|
||||||
|
- const: hdp
|
||||||
|
|
||||||
|
"#sound-dai-cells":
|
||||||
|
const: 0
|
||||||
|
|
||||||
|
rockchip,grf:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/phandle
|
||||||
|
description:
|
||||||
|
Some HDMI QP related data is accessed through SYS GRF regs.
|
||||||
|
|
||||||
|
rockchip,vo-grf:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/phandle
|
||||||
|
description:
|
||||||
|
Additional HDMI QP related data is accessed through VO GRF regs.
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
- clocks
|
||||||
|
- clock-names
|
||||||
|
- interrupts
|
||||||
|
- interrupt-names
|
||||||
|
- phys
|
||||||
|
- ports
|
||||||
|
- resets
|
||||||
|
- reset-names
|
||||||
|
- rockchip,grf
|
||||||
|
- rockchip,vo-grf
|
||||||
|
|
||||||
|
unevaluatedProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
#include <dt-bindings/clock/rockchip,rk3588-cru.h>
|
||||||
|
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||||
|
#include <dt-bindings/interrupt-controller/irq.h>
|
||||||
|
#include <dt-bindings/power/rk3588-power.h>
|
||||||
|
#include <dt-bindings/reset/rockchip,rk3588-cru.h>
|
||||||
|
|
||||||
|
soc {
|
||||||
|
#address-cells = <2>;
|
||||||
|
#size-cells = <2>;
|
||||||
|
|
||||||
|
hdmi@fde80000 {
|
||||||
|
compatible = "rockchip,rk3588-dw-hdmi-qp";
|
||||||
|
reg = <0x0 0xfde80000 0x0 0x20000>;
|
||||||
|
clocks = <&cru PCLK_HDMITX0>,
|
||||||
|
<&cru CLK_HDMITX0_EARC>,
|
||||||
|
<&cru CLK_HDMITX0_REF>,
|
||||||
|
<&cru MCLK_I2S5_8CH_TX>,
|
||||||
|
<&cru CLK_HDMIHDP0>,
|
||||||
|
<&cru HCLK_VO1>;
|
||||||
|
clock-names = "pclk", "earc", "ref", "aud", "hdp", "hclk_vo1";
|
||||||
|
interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH 0>,
|
||||||
|
<GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH 0>,
|
||||||
|
<GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH 0>,
|
||||||
|
<GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH 0>,
|
||||||
|
<GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH 0>;
|
||||||
|
interrupt-names = "avp", "cec", "earc", "main", "hpd";
|
||||||
|
phys = <&hdptxphy_hdmi0>;
|
||||||
|
power-domains = <&power RK3588_PD_VO1>;
|
||||||
|
resets = <&cru SRST_HDMITX0_REF>, <&cru SRST_HDMIHDP0>;
|
||||||
|
reset-names = "ref", "hdp";
|
||||||
|
rockchip,grf = <&sys_grf>;
|
||||||
|
rockchip,vo-grf = <&vo1_grf>;
|
||||||
|
#sound-dai-cells = <0>;
|
||||||
|
|
||||||
|
ports {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
port@0 {
|
||||||
|
reg = <0>;
|
||||||
|
|
||||||
|
hdmi0_in_vp0: endpoint {
|
||||||
|
remote-endpoint = <&vp0_out_hdmi0>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
port@1 {
|
||||||
|
reg = <1>;
|
||||||
|
|
||||||
|
hdmi0_out_con0: endpoint {
|
||||||
|
remote-endpoint = <&hdmi_con0_in>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
@@ -0,0 +1,92 @@
|
|||||||
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/display/sharp,ls010b7dh04.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: Sharp Memory LCD panels
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Alex Lanzano <lanzano.alex@gmail.com>
|
||||||
|
|
||||||
|
description:
|
||||||
|
Sharp Memory LCDs are a series of monochrome displays that operate over
|
||||||
|
a SPI bus. The displays require a signal (VCOM) to be generated to prevent
|
||||||
|
DC bias build up resulting in pixels being unable to change. Three modes
|
||||||
|
can be used to provide the VCOM signal ("software", "external", "pwm").
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
enum:
|
||||||
|
- sharp,ls010b7dh04
|
||||||
|
- sharp,ls011b7dh03
|
||||||
|
- sharp,ls012b7dd01
|
||||||
|
- sharp,ls013b7dh03
|
||||||
|
- sharp,ls013b7dh05
|
||||||
|
- sharp,ls018b7dh02
|
||||||
|
- sharp,ls027b7dh01
|
||||||
|
- sharp,ls027b7dh01a
|
||||||
|
- sharp,ls032b7dd02
|
||||||
|
- sharp,ls044q7dh01
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
spi-max-frequency:
|
||||||
|
maximum: 2000000
|
||||||
|
|
||||||
|
sharp,vcom-mode:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/string
|
||||||
|
description: |
|
||||||
|
software - This mode relies on a software operation to send a
|
||||||
|
"maintain display" message to the display, toggling the vcom
|
||||||
|
bit on and off with each message
|
||||||
|
|
||||||
|
external - This mode relies on an external clock to generate
|
||||||
|
the signal on the EXTCOMM pin
|
||||||
|
|
||||||
|
pwm - This mode relies on a pwm device to generate the signal
|
||||||
|
on the EXTCOMM pin
|
||||||
|
|
||||||
|
enum: [software, external, pwm]
|
||||||
|
|
||||||
|
enable-gpios: true
|
||||||
|
|
||||||
|
pwms:
|
||||||
|
maxItems: 1
|
||||||
|
description: External VCOM signal
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
- sharp,vcom-mode
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- $ref: panel/panel-common.yaml#
|
||||||
|
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||||
|
|
||||||
|
- if:
|
||||||
|
properties:
|
||||||
|
sharp,vcom-mode:
|
||||||
|
const: pwm
|
||||||
|
then:
|
||||||
|
required:
|
||||||
|
- pwms
|
||||||
|
|
||||||
|
unevaluatedProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
spi {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
display@0 {
|
||||||
|
compatible = "sharp,ls013b7dh03";
|
||||||
|
reg = <0>;
|
||||||
|
spi-cs-high;
|
||||||
|
spi-max-frequency = <1000000>;
|
||||||
|
sharp,vcom-mode = "software";
|
||||||
|
};
|
||||||
|
};
|
||||||
|
...
|
||||||
@@ -26,6 +26,7 @@ properties:
|
|||||||
- renesas,r9a07g054-mali
|
- renesas,r9a07g054-mali
|
||||||
- rockchip,px30-mali
|
- rockchip,px30-mali
|
||||||
- rockchip,rk3568-mali
|
- rockchip,rk3568-mali
|
||||||
|
- rockchip,rk3576-mali
|
||||||
- const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable
|
- const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable
|
||||||
- items:
|
- items:
|
||||||
- enum:
|
- enum:
|
||||||
|
|||||||
@@ -67,6 +67,10 @@ properties:
|
|||||||
A 2.5V to 3.3V supply for the external reference voltage. When omitted,
|
A 2.5V to 3.3V supply for the external reference voltage. When omitted,
|
||||||
the internal 2.5V reference is used.
|
the internal 2.5V reference is used.
|
||||||
|
|
||||||
|
refin-supply:
|
||||||
|
description:
|
||||||
|
A 2.5V to 3.3V supply for external reference voltage, for ad7380-4 only.
|
||||||
|
|
||||||
aina-supply:
|
aina-supply:
|
||||||
description:
|
description:
|
||||||
The common mode voltage supply for the AINA- pin on pseudo-differential
|
The common mode voltage supply for the AINA- pin on pseudo-differential
|
||||||
@@ -135,6 +139,23 @@ allOf:
|
|||||||
ainc-supply: false
|
ainc-supply: false
|
||||||
aind-supply: false
|
aind-supply: false
|
||||||
|
|
||||||
|
# ad7380-4 uses refin-supply as external reference.
|
||||||
|
# All other chips from ad738x family use refio as optional external reference.
|
||||||
|
# When refio-supply is omitted, internal reference is used.
|
||||||
|
- if:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
enum:
|
||||||
|
- adi,ad7380-4
|
||||||
|
then:
|
||||||
|
properties:
|
||||||
|
refio-supply: false
|
||||||
|
required:
|
||||||
|
- refin-supply
|
||||||
|
else:
|
||||||
|
properties:
|
||||||
|
refin-supply: false
|
||||||
|
|
||||||
examples:
|
examples:
|
||||||
- |
|
- |
|
||||||
#include <dt-bindings/interrupt-controller/irq.h>
|
#include <dt-bindings/interrupt-controller/irq.h>
|
||||||
|
|||||||
@@ -4,7 +4,7 @@
|
|||||||
$id: http://devicetree.org/schemas/iio/dac/adi,ad5686.yaml#
|
$id: http://devicetree.org/schemas/iio/dac/adi,ad5686.yaml#
|
||||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: Analog Devices AD5360 and similar DACs
|
title: Analog Devices AD5360 and similar SPI DACs
|
||||||
|
|
||||||
maintainers:
|
maintainers:
|
||||||
- Michael Hennerich <michael.hennerich@analog.com>
|
- Michael Hennerich <michael.hennerich@analog.com>
|
||||||
@@ -12,8 +12,6 @@ maintainers:
|
|||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
oneOf:
|
|
||||||
- description: SPI devices
|
|
||||||
enum:
|
enum:
|
||||||
- adi,ad5310r
|
- adi,ad5310r
|
||||||
- adi,ad5672r
|
- adi,ad5672r
|
||||||
@@ -30,23 +28,6 @@ properties:
|
|||||||
- adi,ad5685r
|
- adi,ad5685r
|
||||||
- adi,ad5686
|
- adi,ad5686
|
||||||
- adi,ad5686r
|
- adi,ad5686r
|
||||||
- description: I2C devices
|
|
||||||
enum:
|
|
||||||
- adi,ad5311r
|
|
||||||
- adi,ad5337r
|
|
||||||
- adi,ad5338r
|
|
||||||
- adi,ad5671r
|
|
||||||
- adi,ad5675r
|
|
||||||
- adi,ad5691r
|
|
||||||
- adi,ad5692r
|
|
||||||
- adi,ad5693
|
|
||||||
- adi,ad5693r
|
|
||||||
- adi,ad5694
|
|
||||||
- adi,ad5694r
|
|
||||||
- adi,ad5695r
|
|
||||||
- adi,ad5696
|
|
||||||
- adi,ad5696r
|
|
||||||
|
|
||||||
|
|
||||||
reg:
|
reg:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|||||||
@@ -4,7 +4,7 @@
|
|||||||
$id: http://devicetree.org/schemas/iio/dac/adi,ad5696.yaml#
|
$id: http://devicetree.org/schemas/iio/dac/adi,ad5696.yaml#
|
||||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: Analog Devices AD5696 and similar multi-channel DACs
|
title: Analog Devices AD5696 and similar I2C multi-channel DACs
|
||||||
|
|
||||||
maintainers:
|
maintainers:
|
||||||
- Michael Auchter <michael.auchter@ni.com>
|
- Michael Auchter <michael.auchter@ni.com>
|
||||||
@@ -16,6 +16,7 @@ properties:
|
|||||||
compatible:
|
compatible:
|
||||||
enum:
|
enum:
|
||||||
- adi,ad5311r
|
- adi,ad5311r
|
||||||
|
- adi,ad5337r
|
||||||
- adi,ad5338r
|
- adi,ad5338r
|
||||||
- adi,ad5671r
|
- adi,ad5671r
|
||||||
- adi,ad5675r
|
- adi,ad5675r
|
||||||
|
|||||||
@@ -82,9 +82,6 @@ allOf:
|
|||||||
enum:
|
enum:
|
||||||
- fsl,ls1043a-extirq
|
- fsl,ls1043a-extirq
|
||||||
- fsl,ls1046a-extirq
|
- fsl,ls1046a-extirq
|
||||||
- fsl,ls1088a-extirq
|
|
||||||
- fsl,ls2080a-extirq
|
|
||||||
- fsl,lx2160a-extirq
|
|
||||||
then:
|
then:
|
||||||
properties:
|
properties:
|
||||||
interrupt-map:
|
interrupt-map:
|
||||||
@@ -95,6 +92,29 @@ allOf:
|
|||||||
- const: 0xf
|
- const: 0xf
|
||||||
- const: 0
|
- const: 0
|
||||||
|
|
||||||
|
- if:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
contains:
|
||||||
|
enum:
|
||||||
|
- fsl,ls1088a-extirq
|
||||||
|
- fsl,ls2080a-extirq
|
||||||
|
- fsl,lx2160a-extirq
|
||||||
|
# The driver(drivers/irqchip/irq-ls-extirq.c) have not use standard DT
|
||||||
|
# function to parser interrupt-map. So it doesn't consider '#address-size'
|
||||||
|
# in parent interrupt controller, such as GIC.
|
||||||
|
#
|
||||||
|
# When dt-binding verify interrupt-map, item data matrix is spitted at
|
||||||
|
# incorrect position. Remove interrupt-map restriction because it always
|
||||||
|
# wrong.
|
||||||
|
|
||||||
|
then:
|
||||||
|
properties:
|
||||||
|
interrupt-map-mask:
|
||||||
|
items:
|
||||||
|
- const: 0xf
|
||||||
|
- const: 0
|
||||||
|
|
||||||
additionalProperties: false
|
additionalProperties: false
|
||||||
|
|
||||||
examples:
|
examples:
|
||||||
|
|||||||
@@ -113,7 +113,7 @@ properties:
|
|||||||
|
|
||||||
msi-parent:
|
msi-parent:
|
||||||
deprecated: true
|
deprecated: true
|
||||||
$ref: /schemas/types.yaml#/definitions/phandle
|
maxItems: 1
|
||||||
description:
|
description:
|
||||||
Describes the MSI controller node handling message
|
Describes the MSI controller node handling message
|
||||||
interrupts for the MC. When there is no translation
|
interrupts for the MC. When there is no translation
|
||||||
|
|||||||
@@ -26,6 +26,7 @@ properties:
|
|||||||
- brcm,asp-v2.1-mdio
|
- brcm,asp-v2.1-mdio
|
||||||
- brcm,asp-v2.2-mdio
|
- brcm,asp-v2.2-mdio
|
||||||
- brcm,unimac-mdio
|
- brcm,unimac-mdio
|
||||||
|
- brcm,bcm6846-mdio
|
||||||
|
|
||||||
reg:
|
reg:
|
||||||
minItems: 1
|
minItems: 1
|
||||||
|
|||||||
@@ -34,6 +34,7 @@ properties:
|
|||||||
and length of the AXI DMA controller IO space, unless
|
and length of the AXI DMA controller IO space, unless
|
||||||
axistream-connected is specified, in which case the reg
|
axistream-connected is specified, in which case the reg
|
||||||
attribute of the node referenced by it is used.
|
attribute of the node referenced by it is used.
|
||||||
|
minItems: 1
|
||||||
maxItems: 2
|
maxItems: 2
|
||||||
|
|
||||||
interrupts:
|
interrupts:
|
||||||
@@ -181,7 +182,7 @@ examples:
|
|||||||
clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
|
clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
|
||||||
clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
|
clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
|
||||||
phy-mode = "mii";
|
phy-mode = "mii";
|
||||||
reg = <0x00 0x40000000 0x00 0x40000>;
|
reg = <0x40000000 0x40000>;
|
||||||
xlnx,rxcsum = <0x2>;
|
xlnx,rxcsum = <0x2>;
|
||||||
xlnx,rxmem = <0x800>;
|
xlnx,rxmem = <0x800>;
|
||||||
xlnx,txcsum = <0x2>;
|
xlnx,txcsum = <0x2>;
|
||||||
|
|||||||
@@ -154,8 +154,6 @@ allOf:
|
|||||||
- qcom,sm8550-qmp-gen4x2-pcie-phy
|
- qcom,sm8550-qmp-gen4x2-pcie-phy
|
||||||
- qcom,sm8650-qmp-gen3x2-pcie-phy
|
- qcom,sm8650-qmp-gen3x2-pcie-phy
|
||||||
- qcom,sm8650-qmp-gen4x2-pcie-phy
|
- qcom,sm8650-qmp-gen4x2-pcie-phy
|
||||||
- qcom,x1e80100-qmp-gen3x2-pcie-phy
|
|
||||||
- qcom,x1e80100-qmp-gen4x2-pcie-phy
|
|
||||||
then:
|
then:
|
||||||
properties:
|
properties:
|
||||||
clocks:
|
clocks:
|
||||||
@@ -171,6 +169,8 @@ allOf:
|
|||||||
- qcom,sc8280xp-qmp-gen3x1-pcie-phy
|
- qcom,sc8280xp-qmp-gen3x1-pcie-phy
|
||||||
- qcom,sc8280xp-qmp-gen3x2-pcie-phy
|
- qcom,sc8280xp-qmp-gen3x2-pcie-phy
|
||||||
- qcom,sc8280xp-qmp-gen3x4-pcie-phy
|
- qcom,sc8280xp-qmp-gen3x4-pcie-phy
|
||||||
|
- qcom,x1e80100-qmp-gen3x2-pcie-phy
|
||||||
|
- qcom,x1e80100-qmp-gen4x2-pcie-phy
|
||||||
- qcom,x1e80100-qmp-gen4x4-pcie-phy
|
- qcom,x1e80100-qmp-gen4x4-pcie-phy
|
||||||
then:
|
then:
|
||||||
properties:
|
properties:
|
||||||
@@ -201,6 +201,7 @@ allOf:
|
|||||||
- qcom,sm8550-qmp-gen4x2-pcie-phy
|
- qcom,sm8550-qmp-gen4x2-pcie-phy
|
||||||
- qcom,sm8650-qmp-gen4x2-pcie-phy
|
- qcom,sm8650-qmp-gen4x2-pcie-phy
|
||||||
- qcom,x1e80100-qmp-gen4x2-pcie-phy
|
- qcom,x1e80100-qmp-gen4x2-pcie-phy
|
||||||
|
- qcom,x1e80100-qmp-gen4x4-pcie-phy
|
||||||
then:
|
then:
|
||||||
properties:
|
properties:
|
||||||
resets:
|
resets:
|
||||||
|
|||||||
@@ -102,21 +102,21 @@ properties:
|
|||||||
default: 2
|
default: 2
|
||||||
|
|
||||||
interrupts:
|
interrupts:
|
||||||
anyOf:
|
minItems: 1
|
||||||
- minItems: 1
|
maxItems: 2
|
||||||
items:
|
|
||||||
- description: TX interrupt
|
|
||||||
- description: RX interrupt
|
|
||||||
- items:
|
|
||||||
- description: common/combined interrupt
|
|
||||||
|
|
||||||
interrupt-names:
|
interrupt-names:
|
||||||
oneOf:
|
oneOf:
|
||||||
- minItems: 1
|
- description: TX interrupt
|
||||||
|
const: tx
|
||||||
|
- description: RX interrupt
|
||||||
|
const: rx
|
||||||
|
- description: TX and RX interrupts
|
||||||
items:
|
items:
|
||||||
- const: tx
|
- const: tx
|
||||||
- const: rx
|
- const: rx
|
||||||
- const: common
|
- description: Common/combined interrupt
|
||||||
|
const: common
|
||||||
|
|
||||||
fck_parent:
|
fck_parent:
|
||||||
$ref: /schemas/types.yaml#/definitions/string
|
$ref: /schemas/types.yaml#/definitions/string
|
||||||
|
|||||||
@@ -30,6 +30,7 @@ properties:
|
|||||||
- qcom,apq8096-sndcard
|
- qcom,apq8096-sndcard
|
||||||
- qcom,qcm6490-idp-sndcard
|
- qcom,qcm6490-idp-sndcard
|
||||||
- qcom,qcs6490-rb3gen2-sndcard
|
- qcom,qcs6490-rb3gen2-sndcard
|
||||||
|
- qcom,qrb4210-rb2-sndcard
|
||||||
- qcom,qrb5165-rb5-sndcard
|
- qcom,qrb5165-rb5-sndcard
|
||||||
- qcom,sc7180-qdsp6-sndcard
|
- qcom,sc7180-qdsp6-sndcard
|
||||||
- qcom,sc8280xp-sndcard
|
- qcom,sc8280xp-sndcard
|
||||||
|
|||||||
@@ -302,7 +302,7 @@ allOf:
|
|||||||
reg-names:
|
reg-names:
|
||||||
items:
|
items:
|
||||||
enum:
|
enum:
|
||||||
- scu
|
- sru
|
||||||
- ssi
|
- ssi
|
||||||
- adg
|
- adg
|
||||||
# for Gen2/Gen3
|
# for Gen2/Gen3
|
||||||
|
|||||||
@@ -48,6 +48,10 @@ properties:
|
|||||||
- const: mclk_rx
|
- const: mclk_rx
|
||||||
- const: hclk
|
- const: hclk
|
||||||
|
|
||||||
|
port:
|
||||||
|
$ref: audio-graph-port.yaml#
|
||||||
|
unevaluatedProperties: false
|
||||||
|
|
||||||
resets:
|
resets:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
||||||
|
|||||||
@@ -101,8 +101,6 @@ properties:
|
|||||||
- domintech,dmard09
|
- domintech,dmard09
|
||||||
# DMARD10: 3-axis Accelerometer
|
# DMARD10: 3-axis Accelerometer
|
||||||
- domintech,dmard10
|
- domintech,dmard10
|
||||||
# Elgin SPI-controlled LCD
|
|
||||||
- elgin,jg10309-01
|
|
||||||
# MMA7660FC: 3-Axis Orientation/Motion Detection Sensor
|
# MMA7660FC: 3-Axis Orientation/Motion Detection Sensor
|
||||||
- fsl,mma7660
|
- fsl,mma7660
|
||||||
# MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
|
# MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
|
||||||
|
|||||||
@@ -752,6 +752,8 @@ patternProperties:
|
|||||||
description: Japan Display Inc.
|
description: Japan Display Inc.
|
||||||
"^jedec,.*":
|
"^jedec,.*":
|
||||||
description: JEDEC Solid State Technology Association
|
description: JEDEC Solid State Technology Association
|
||||||
|
"^jenson,.*":
|
||||||
|
description: Jenson Display Co. Ltd.
|
||||||
"^jesurun,.*":
|
"^jesurun,.*":
|
||||||
description: Shenzhen Jesurun Electronics Business Dept.
|
description: Shenzhen Jesurun Electronics Business Dept.
|
||||||
"^jethome,.*":
|
"^jethome,.*":
|
||||||
|
|||||||
@@ -7,12 +7,11 @@ WMI Driver API
|
|||||||
The WMI driver core supports a more modern bus-based interface for interacting
|
The WMI driver core supports a more modern bus-based interface for interacting
|
||||||
with WMI devices, and an older GUID-based interface. The latter interface is
|
with WMI devices, and an older GUID-based interface. The latter interface is
|
||||||
considered to be deprecated, so new WMI drivers should generally avoid it since
|
considered to be deprecated, so new WMI drivers should generally avoid it since
|
||||||
it has some issues with multiple WMI devices and events sharing the same GUIDs
|
it has some issues with multiple WMI devices sharing the same GUID.
|
||||||
and/or notification IDs. The modern bus-based interface instead maps each
|
The modern bus-based interface instead maps each WMI device to a
|
||||||
WMI device to a :c:type:`struct wmi_device <wmi_device>`, so it supports
|
:c:type:`struct wmi_device <wmi_device>`, so it supports WMI devices sharing the
|
||||||
WMI devices sharing GUIDs and/or notification IDs. Drivers can then register
|
same GUID. Drivers can then register a :c:type:`struct wmi_driver <wmi_driver>`
|
||||||
a :c:type:`struct wmi_driver <wmi_driver>`, which will be bound to compatible
|
which will be bound to compatible WMI devices by the driver core.
|
||||||
WMI devices by the driver core.
|
|
||||||
|
|
||||||
.. kernel-doc:: include/linux/wmi.h
|
.. kernel-doc:: include/linux/wmi.h
|
||||||
:internal:
|
:internal:
|
||||||
|
|||||||
@@ -115,7 +115,7 @@ set up cache ready for use. The following script commands are available:
|
|||||||
|
|
||||||
This mask can also be set through sysfs, eg::
|
This mask can also be set through sysfs, eg::
|
||||||
|
|
||||||
echo 5 >/sys/modules/cachefiles/parameters/debug
|
echo 5 > /sys/module/cachefiles/parameters/debug
|
||||||
|
|
||||||
|
|
||||||
Starting the Cache
|
Starting the Cache
|
||||||
|
|||||||
@@ -208,7 +208,7 @@ The filesystem must arrange to `cancel
|
|||||||
such `reservations
|
such `reservations
|
||||||
<https://lore.kernel.org/linux-xfs/20220817093627.GZ3600936@dread.disaster.area/>`_
|
<https://lore.kernel.org/linux-xfs/20220817093627.GZ3600936@dread.disaster.area/>`_
|
||||||
because writeback will not consume the reservation.
|
because writeback will not consume the reservation.
|
||||||
The ``iomap_file_buffered_write_punch_delalloc`` can be called from a
|
The ``iomap_write_delalloc_release`` can be called from a
|
||||||
``->iomap_end`` function to find all the clean areas of the folios
|
``->iomap_end`` function to find all the clean areas of the folios
|
||||||
caching a fresh (``IOMAP_F_NEW``) delalloc mapping.
|
caching a fresh (``IOMAP_F_NEW``) delalloc mapping.
|
||||||
It takes the ``invalidate_lock``.
|
It takes the ``invalidate_lock``.
|
||||||
|
|||||||
@@ -592,4 +592,3 @@ API Function Reference
|
|||||||
|
|
||||||
.. kernel-doc:: include/linux/netfs.h
|
.. kernel-doc:: include/linux/netfs.h
|
||||||
.. kernel-doc:: fs/netfs/buffered_read.c
|
.. kernel-doc:: fs/netfs/buffered_read.c
|
||||||
.. kernel-doc:: fs/netfs/io.c
|
|
||||||
|
|||||||
731
Documentation/gpu/amdgpu/display/dc-arch-overview.svg
Normal file
731
Documentation/gpu/amdgpu/display/dc-arch-overview.svg
Normal file
@@ -0,0 +1,731 @@
|
|||||||
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||||
|
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||||
|
|
||||||
|
<svg
|
||||||
|
width="1204.058"
|
||||||
|
height="510.57321"
|
||||||
|
viewBox="0 0 318.57366 135.08917"
|
||||||
|
version="1.1"
|
||||||
|
id="svg8"
|
||||||
|
inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
|
||||||
|
sodipodi:docname="dc-arch-overview.svg"
|
||||||
|
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||||
|
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||||
|
xmlns="http://www.w3.org/2000/svg"
|
||||||
|
xmlns:svg="http://www.w3.org/2000/svg"
|
||||||
|
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||||
|
xmlns:cc="http://creativecommons.org/ns#"
|
||||||
|
xmlns:dc="http://purl.org/dc/elements/1.1/">
|
||||||
|
<defs
|
||||||
|
id="defs2">
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="marker8858"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path8616"
|
||||||
|
style="fill:#aa00d4;fill-opacity:1;fill-rule:evenodd;stroke:#aa00d4;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Send"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Send"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path8622"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="matrix(-0.3,0,0,-0.3,0.69,0)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow1Lend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow1Lend"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path8592"
|
||||||
|
d="M 0,0 5,-5 -12.5,0 5,5 Z"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1pt;stroke-opacity:1"
|
||||||
|
transform="matrix(-0.8,0,0,-0.8,-10,0)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Lend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Lend"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path8610"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path1200"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-2"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-9"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-2-1"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-9-9"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-2-7"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-9-8"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-4"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-5"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-0"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-3"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-6"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-1"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-2-6"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-9-1"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-0-7"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-3-4"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-6-3"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-1-0"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-2-8"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-9-6"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-3"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path1200-6"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="marker8858-3"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path8616-5"
|
||||||
|
style="fill:#00ffcc;fill-opacity:1;fill-rule:evenodd;stroke:#00ffcc;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-3"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-56"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-0-2"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-3-9"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
</defs>
|
||||||
|
<sodipodi:namedview
|
||||||
|
id="base"
|
||||||
|
pagecolor="#ffffff"
|
||||||
|
bordercolor="#666666"
|
||||||
|
borderopacity="1.0"
|
||||||
|
inkscape:pageopacity="0.0"
|
||||||
|
inkscape:pageshadow="2"
|
||||||
|
inkscape:zoom="1.4"
|
||||||
|
inkscape:cx="812.5"
|
||||||
|
inkscape:cy="315"
|
||||||
|
inkscape:document-units="mm"
|
||||||
|
inkscape:current-layer="layer1"
|
||||||
|
showgrid="false"
|
||||||
|
inkscape:window-width="3840"
|
||||||
|
inkscape:window-height="2083"
|
||||||
|
inkscape:window-x="0"
|
||||||
|
inkscape:window-y="0"
|
||||||
|
inkscape:window-maximized="1"
|
||||||
|
showguides="false"
|
||||||
|
fit-margin-top="0"
|
||||||
|
fit-margin-left="0"
|
||||||
|
fit-margin-right="0"
|
||||||
|
fit-margin-bottom="0"
|
||||||
|
units="px"
|
||||||
|
inkscape:snap-global="false"
|
||||||
|
inkscape:showpageshadow="2"
|
||||||
|
inkscape:pagecheckerboard="0"
|
||||||
|
inkscape:deskcolor="#d1d1d1" />
|
||||||
|
<metadata
|
||||||
|
id="metadata5">
|
||||||
|
<rdf:RDF>
|
||||||
|
<cc:Work
|
||||||
|
rdf:about="">
|
||||||
|
<dc:format>image/svg+xml</dc:format>
|
||||||
|
<dc:type
|
||||||
|
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||||
|
</cc:Work>
|
||||||
|
</rdf:RDF>
|
||||||
|
</metadata>
|
||||||
|
<g
|
||||||
|
inkscape:label="Layer 1"
|
||||||
|
inkscape:groupmode="layer"
|
||||||
|
id="layer1"
|
||||||
|
transform="translate(399.57097,11.171866)">
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:6.54816px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704"
|
||||||
|
x="-297.75696"
|
||||||
|
y="109.44505"
|
||||||
|
id="text1063" />
|
||||||
|
<path
|
||||||
|
style="fill:#008000;stroke:#008000;stroke-width:0.463298;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.463298, 0.926596;stroke-dashoffset:0;stroke-opacity:1"
|
||||||
|
d="m -120.41395,84.001461 h -9.04766"
|
||||||
|
id="path1171-0-7"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
<path
|
||||||
|
style="fill:none;stroke:#ff0000;stroke-width:0.982225;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.982225, 1.96445;stroke-dashoffset:0;stroke-opacity:1"
|
||||||
|
d="m -129.96274,90.649221 h 8.66407"
|
||||||
|
id="path1171-7-1-3-8"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
<path
|
||||||
|
style="fill:none;stroke:#3771c8;stroke-width:0.745037;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
|
||||||
|
d="m -121.33167,97.283841 h -7.91265"
|
||||||
|
id="path7149-3-7-8"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:6.54816px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704"
|
||||||
|
x="-115.55721"
|
||||||
|
y="85.330681"
|
||||||
|
id="text12079"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
id="tspan12077"
|
||||||
|
x="-115.55721"
|
||||||
|
y="85.330681"
|
||||||
|
style="font-size:4.80199px;stroke-width:0.163704">Board/Platform</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:6.54816px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704"
|
||||||
|
x="-115.75885"
|
||||||
|
y="92.435066"
|
||||||
|
id="text12079-3"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
id="tspan12077-1"
|
||||||
|
x="-115.75885"
|
||||||
|
y="92.435066"
|
||||||
|
style="font-size:4.80199px;stroke-width:0.163704">SoC</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:6.54816px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704"
|
||||||
|
x="-115.6041"
|
||||||
|
y="98.608604"
|
||||||
|
id="text12079-3-4"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
id="tspan12077-1-9"
|
||||||
|
x="-115.6041"
|
||||||
|
y="98.608604"
|
||||||
|
style="font-size:4.80199px;stroke-width:0.163704">Component</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-368.54205"
|
||||||
|
y="92.633011"
|
||||||
|
id="text1010-5"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-368.54205"
|
||||||
|
y="92.633011"
|
||||||
|
style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan1057">DRAM</tspan></text>
|
||||||
|
<g
|
||||||
|
id="g730"
|
||||||
|
transform="translate(6.9386906,-2.5203356)">
|
||||||
|
<text
|
||||||
|
id="text838-5-2-6-2"
|
||||||
|
y="32.372173"
|
||||||
|
x="-372.97867"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704"
|
||||||
|
xml:space="preserve"><tspan
|
||||||
|
id="tspan936-1-2-3"
|
||||||
|
style="text-align:center;text-anchor:middle;stroke-width:0.163704"
|
||||||
|
y="32.372173"
|
||||||
|
x="-372.97867"
|
||||||
|
sodipodi:role="line">dc_plane</tspan></text>
|
||||||
|
<rect
|
||||||
|
ry="6.9139691e-07"
|
||||||
|
y="18.717371"
|
||||||
|
x="-390.50565"
|
||||||
|
height="23.904575"
|
||||||
|
width="35.080177"
|
||||||
|
id="rect834-5-2-6-75"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.561714;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
</g>
|
||||||
|
<g
|
||||||
|
id="g738"
|
||||||
|
transform="translate(6.9386906,31.346346)">
|
||||||
|
<text
|
||||||
|
id="text734"
|
||||||
|
y="32.372173"
|
||||||
|
x="-372.97867"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704"
|
||||||
|
xml:space="preserve"><tspan
|
||||||
|
id="tspan732"
|
||||||
|
style="text-align:center;text-anchor:middle;stroke-width:0.163704"
|
||||||
|
y="32.372173"
|
||||||
|
x="-372.97867"
|
||||||
|
sodipodi:role="line">dc_plane</tspan></text>
|
||||||
|
<rect
|
||||||
|
ry="6.9139691e-07"
|
||||||
|
y="18.717371"
|
||||||
|
x="-390.50565"
|
||||||
|
height="23.904575"
|
||||||
|
width="35.080177"
|
||||||
|
id="rect736"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.561714;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
</g>
|
||||||
|
<rect
|
||||||
|
ry="2.1256196e-06"
|
||||||
|
y="8.5983658"
|
||||||
|
x="-389.18051"
|
||||||
|
height="73.491852"
|
||||||
|
width="46.307304"
|
||||||
|
id="rect744"
|
||||||
|
style="fill:none;stroke:#3771c8;stroke-width:1.13159;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<g
|
||||||
|
id="g757"
|
||||||
|
transform="translate(-19.949528,-8.6078171)">
|
||||||
|
<text
|
||||||
|
id="text600"
|
||||||
|
y="56.289795"
|
||||||
|
x="-256.91336"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704"
|
||||||
|
xml:space="preserve"><tspan
|
||||||
|
id="tspan598"
|
||||||
|
style="text-align:center;text-anchor:middle;stroke-width:0.163704"
|
||||||
|
y="56.289795"
|
||||||
|
x="-256.91336"
|
||||||
|
sodipodi:role="line">DC</tspan></text>
|
||||||
|
<rect
|
||||||
|
ry="1.7458606e-06"
|
||||||
|
y="23.771139"
|
||||||
|
x="-289.21854"
|
||||||
|
height="60.361938"
|
||||||
|
width="65.042557"
|
||||||
|
id="rect602"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:1.21541;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
</g>
|
||||||
|
<rect
|
||||||
|
ry="2.3633565e-06"
|
||||||
|
y="4.4885707"
|
||||||
|
x="-316.43292"
|
||||||
|
height="81.711441"
|
||||||
|
width="79.57225"
|
||||||
|
id="rect787"
|
||||||
|
style="fill:none;stroke:#3771c8;stroke-width:1.5641;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<g
|
||||||
|
id="g765"
|
||||||
|
transform="translate(6.5577393,-7.020317)">
|
||||||
|
<text
|
||||||
|
id="text608"
|
||||||
|
y="31.942825"
|
||||||
|
x="-189.71797"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704"
|
||||||
|
xml:space="preserve"><tspan
|
||||||
|
id="tspan606"
|
||||||
|
style="text-align:center;text-anchor:middle;stroke-width:0.163704"
|
||||||
|
y="31.942825"
|
||||||
|
x="-189.71797"
|
||||||
|
sodipodi:role="line">dc_link</tspan></text>
|
||||||
|
<rect
|
||||||
|
ry="6.8036792e-07"
|
||||||
|
y="18.197111"
|
||||||
|
x="-211.99069"
|
||||||
|
height="23.523254"
|
||||||
|
width="44.846642"
|
||||||
|
id="rect610"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.630025;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
</g>
|
||||||
|
<rect
|
||||||
|
ry="1.0582555e-06"
|
||||||
|
y="4.3160448"
|
||||||
|
x="-210.69141"
|
||||||
|
height="36.588463"
|
||||||
|
width="55.543594"
|
||||||
|
id="rect794"
|
||||||
|
style="fill:none;stroke:#3771c8;stroke-width:0.874443;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<g
|
||||||
|
id="g781"
|
||||||
|
transform="translate(6.5577393,37.542802)">
|
||||||
|
<text
|
||||||
|
id="text777"
|
||||||
|
y="31.942825"
|
||||||
|
x="-189.71797"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704"
|
||||||
|
xml:space="preserve"><tspan
|
||||||
|
id="tspan775"
|
||||||
|
style="text-align:center;text-anchor:middle;stroke-width:0.163704"
|
||||||
|
y="31.942825"
|
||||||
|
x="-189.71797"
|
||||||
|
sodipodi:role="line">dc_link</tspan></text>
|
||||||
|
<rect
|
||||||
|
ry="6.8036792e-07"
|
||||||
|
y="18.197111"
|
||||||
|
x="-211.99069"
|
||||||
|
height="23.523254"
|
||||||
|
width="44.846642"
|
||||||
|
id="rect779"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.630025;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
</g>
|
||||||
|
<rect
|
||||||
|
ry="1.0582555e-06"
|
||||||
|
y="50.466679"
|
||||||
|
x="-210.69141"
|
||||||
|
height="36.588463"
|
||||||
|
width="55.543594"
|
||||||
|
id="rect796"
|
||||||
|
style="fill:none;stroke:#3771c8;stroke-width:0.874443;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<g
|
||||||
|
id="g2151"
|
||||||
|
transform="translate(2.1659807,-25.895798)">
|
||||||
|
<rect
|
||||||
|
ry="9.2671934e-07"
|
||||||
|
y="29.395185"
|
||||||
|
x="-132.25786"
|
||||||
|
height="32.040688"
|
||||||
|
width="44.742229"
|
||||||
|
id="rect618"
|
||||||
|
style="fill:none;stroke:#3771c8;stroke-width:0.734435;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<g
|
||||||
|
id="g838"
|
||||||
|
transform="translate(1.9073486e-6,0.26687336)">
|
||||||
|
<text
|
||||||
|
id="text616"
|
||||||
|
y="47.132744"
|
||||||
|
x="-110.03735"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704"
|
||||||
|
xml:space="preserve"><tspan
|
||||||
|
id="tspan614"
|
||||||
|
style="text-align:center;text-anchor:middle;stroke-width:0.163704"
|
||||||
|
y="47.132744"
|
||||||
|
x="-110.03735"
|
||||||
|
sodipodi:role="line">dc_link</tspan></text>
|
||||||
|
<rect
|
||||||
|
ry="5.7260945e-07"
|
||||||
|
y="35.249866"
|
||||||
|
x="-126.21788"
|
||||||
|
height="19.797579"
|
||||||
|
width="32.66227"
|
||||||
|
id="rect833"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.493257;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
</g>
|
||||||
|
</g>
|
||||||
|
<rect
|
||||||
|
ry="3.6076738e-06"
|
||||||
|
y="-9.4559708"
|
||||||
|
x="-397.85507"
|
||||||
|
height="124.73286"
|
||||||
|
width="250.94243"
|
||||||
|
id="rect1307"
|
||||||
|
style="fill:none;stroke:#008000;stroke-width:3.43179;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:6.86358, 3.43179;stroke-dashoffset:0" />
|
||||||
|
<rect
|
||||||
|
ry="2.9172609e-06"
|
||||||
|
y="-4.5401988"
|
||||||
|
x="-393.52301"
|
||||||
|
height="100.8623"
|
||||||
|
width="174.14117"
|
||||||
|
id="rect1990"
|
||||||
|
style="fill:none;stroke:#ff0000;stroke-width:2.57074;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:2.57074, 5.14148;stroke-dashoffset:0" />
|
||||||
|
<path
|
||||||
|
style="fill:none;stroke:#aa00d4;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
|
||||||
|
d="m -317.69814,47.452094 h -23.80954"
|
||||||
|
id="path2142" />
|
||||||
|
<path
|
||||||
|
style="fill:none;stroke:#aa00d4;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1"
|
||||||
|
d="m -130.71642,19.101665 h -23.80954"
|
||||||
|
id="path2144" />
|
||||||
|
<g
|
||||||
|
aria-label="}"
|
||||||
|
transform="rotate(180,-59.876965,-0.22738225)"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#aa00d4;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
id="text1003-5">
|
||||||
|
<path
|
||||||
|
d="m 92.00239,-21.748413 h 0.86816 c 0,0 15.81267,-0.177767 16.15994,-0.5333 0.35553,-0.355534 1.10026,-1.124479 1.10026,-2.306836 v -20.048953 c 0,-1.289844 0.18603,-2.228288 0.5581,-2.815332 0.37207,-0.587044 0.45004,-0.992187 1.36781,-1.215429 -0.91777,-0.206706 -0.99574,-0.603581 -1.36781,-1.190625 -0.37207,-0.587045 -0.5581,-1.529623 -0.5581,-2.827735 v -19.913761 c 0,-1.174088 -0.74473,-1.938899 -1.10026,-2.294433 -0.34727,-0.363802 -15.00239,-0.545703 -16.15994,-0.545703 h -0.86816 v -1.773536 h 0.78134 c 2.05879,0 17.33403,0.305924 18.02029,0.917774 0.69453,0.60358 1.0418,1.81901 1.0418,3.646289 v 19.814542 c 0,1.231966 0.22324,2.087728 0.66973,2.567285 0.44648,0.471289 1.25677,0.706934 2.43086,0.706934 h 0.76894 v 1.773535 h -0.76894 c -1.17409,0 -1.98438,0.239778 -2.43086,0.719336 -0.44649,0.479557 -0.66973,1.343587 -0.66973,2.59209 v 19.937331 c 0,1.827279 -0.34727,3.046842 -1.0418,3.658691 -0.68626,0.611849 -15.9615,0.917774 -18.02029,0.917774 h -0.78134 z"
|
||||||
|
style="font-size:25.4px;fill:#aa00d4;stroke-width:0.264583"
|
||||||
|
id="path1005-3"
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
sodipodi:nodetypes="cccsscccsscsccscsscsccscsscscc" />
|
||||||
|
</g>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-275.85803"
|
||||||
|
y="92.633011"
|
||||||
|
id="text2157"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-275.85803"
|
||||||
|
y="92.633011"
|
||||||
|
style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan2155">DCN</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-279.29822"
|
||||||
|
y="110.19857"
|
||||||
|
id="text3141"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-279.29822"
|
||||||
|
y="110.19857"
|
||||||
|
style="font-weight:bold;font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan3139">SoC</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-275.85803"
|
||||||
|
y="123.8538"
|
||||||
|
id="text3375"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-275.85803"
|
||||||
|
y="123.8538"
|
||||||
|
style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan3373">Board/Platform</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-107.57491"
|
||||||
|
y="42.939579"
|
||||||
|
id="text3379"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-107.57491"
|
||||||
|
y="42.939579"
|
||||||
|
style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan3377">Display</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-182.71582"
|
||||||
|
y="46.643749"
|
||||||
|
id="text3383"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-182.71582"
|
||||||
|
y="46.643749"
|
||||||
|
style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan3381">Connector</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-182.71582"
|
||||||
|
y="93.210457"
|
||||||
|
id="text3387"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-182.71582"
|
||||||
|
y="93.210457"
|
||||||
|
style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan3385">Connector</tspan></text>
|
||||||
|
</g>
|
||||||
|
</svg>
|
||||||
|
After Width: | Height: | Size: 30 KiB |
732
Documentation/gpu/amdgpu/display/dc-components.svg
Normal file
732
Documentation/gpu/amdgpu/display/dc-components.svg
Normal file
@@ -0,0 +1,732 @@
|
|||||||
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||||
|
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||||
|
|
||||||
|
<svg
|
||||||
|
width="533.42053"
|
||||||
|
height="631.18573"
|
||||||
|
viewBox="0 0 141.13418 167.00122"
|
||||||
|
version="1.1"
|
||||||
|
id="svg8"
|
||||||
|
inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
|
||||||
|
sodipodi:docname="dc-components.svg"
|
||||||
|
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||||
|
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||||
|
xmlns="http://www.w3.org/2000/svg"
|
||||||
|
xmlns:svg="http://www.w3.org/2000/svg"
|
||||||
|
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||||
|
xmlns:cc="http://creativecommons.org/ns#"
|
||||||
|
xmlns:dc="http://purl.org/dc/elements/1.1/">
|
||||||
|
<defs
|
||||||
|
id="defs2">
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="marker8858"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path8616"
|
||||||
|
style="fill:#aa00d4;fill-opacity:1;fill-rule:evenodd;stroke:#aa00d4;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Send"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Send"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path8622"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="matrix(-0.3,0,0,-0.3,0.69,0)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow1Lend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow1Lend"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path8592"
|
||||||
|
d="M 0,0 5,-5 -12.5,0 5,5 Z"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1pt;stroke-opacity:1"
|
||||||
|
transform="matrix(-0.8,0,0,-0.8,-10,0)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Lend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Lend"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path8610"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path1200"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-2"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-9"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-2-1"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-9-9"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-2-7"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-9-8"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-4"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-5"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-0"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-3"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-6"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-1"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-2-6"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-9-1"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-0-7"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-3-4"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-6-3"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-1-0"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-2-8"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-9-6"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-3"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path1200-6"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="marker8858-3"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
id="path8616-5"
|
||||||
|
style="fill:#00ffcc;fill-opacity:1;fill-rule:evenodd;stroke:#00ffcc;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)"
|
||||||
|
inkscape:connector-curvature="0" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-3-3"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-6-56"
|
||||||
|
style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
<marker
|
||||||
|
inkscape:stockid="Arrow2Mend"
|
||||||
|
orient="auto"
|
||||||
|
refY="0"
|
||||||
|
refX="0"
|
||||||
|
id="Arrow2Mend-8-0-2"
|
||||||
|
style="overflow:visible"
|
||||||
|
inkscape:isstock="true">
|
||||||
|
<path
|
||||||
|
inkscape:connector-curvature="0"
|
||||||
|
id="path1200-9-3-9"
|
||||||
|
style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
|
||||||
|
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||||
|
transform="scale(-0.6)" />
|
||||||
|
</marker>
|
||||||
|
</defs>
|
||||||
|
<sodipodi:namedview
|
||||||
|
id="base"
|
||||||
|
pagecolor="#ffffff"
|
||||||
|
bordercolor="#666666"
|
||||||
|
borderopacity="1.0"
|
||||||
|
inkscape:pageopacity="0.0"
|
||||||
|
inkscape:pageshadow="2"
|
||||||
|
inkscape:zoom="1.4"
|
||||||
|
inkscape:cx="482.85714"
|
||||||
|
inkscape:cy="470"
|
||||||
|
inkscape:document-units="mm"
|
||||||
|
inkscape:current-layer="layer1"
|
||||||
|
showgrid="false"
|
||||||
|
inkscape:window-width="3840"
|
||||||
|
inkscape:window-height="2083"
|
||||||
|
inkscape:window-x="0"
|
||||||
|
inkscape:window-y="0"
|
||||||
|
inkscape:window-maximized="1"
|
||||||
|
showguides="false"
|
||||||
|
fit-margin-top="0"
|
||||||
|
fit-margin-left="0"
|
||||||
|
fit-margin-right="0"
|
||||||
|
fit-margin-bottom="0"
|
||||||
|
units="px"
|
||||||
|
inkscape:snap-global="false"
|
||||||
|
inkscape:showpageshadow="2"
|
||||||
|
inkscape:pagecheckerboard="0"
|
||||||
|
inkscape:deskcolor="#d1d1d1" />
|
||||||
|
<metadata
|
||||||
|
id="metadata5">
|
||||||
|
<rdf:RDF>
|
||||||
|
<cc:Work
|
||||||
|
rdf:about="">
|
||||||
|
<dc:format>image/svg+xml</dc:format>
|
||||||
|
<dc:type
|
||||||
|
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||||
|
</cc:Work>
|
||||||
|
</rdf:RDF>
|
||||||
|
</metadata>
|
||||||
|
<g
|
||||||
|
inkscape:label="Layer 1"
|
||||||
|
inkscape:groupmode="layer"
|
||||||
|
id="layer1"
|
||||||
|
transform="translate(384.1992,26.608359)">
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:4.0511px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.101278"
|
||||||
|
x="-330.72058"
|
||||||
|
y="57.56284"
|
||||||
|
id="text1063" />
|
||||||
|
<rect
|
||||||
|
ry="4.7572436e-07"
|
||||||
|
y="-26.142614"
|
||||||
|
x="-383.73346"
|
||||||
|
height="16.447845"
|
||||||
|
width="140.2027"
|
||||||
|
id="rect744"
|
||||||
|
style="fill:none;stroke:#3771c8;stroke-width:0.93149;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<rect
|
||||||
|
ry="1.0800992e-06"
|
||||||
|
y="-5.1415901"
|
||||||
|
x="-383.27942"
|
||||||
|
height="37.343693"
|
||||||
|
width="40.239418"
|
||||||
|
id="rect602"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.751929;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:10.476px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-363.2121"
|
||||||
|
y="17.270189"
|
||||||
|
id="text3379"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-363.2121"
|
||||||
|
y="17.270189"
|
||||||
|
style="font-size:10.476px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan3377">Core</tspan></text>
|
||||||
|
<rect
|
||||||
|
ry="1.0800992e-06"
|
||||||
|
y="-5.1415901"
|
||||||
|
x="-331.06259"
|
||||||
|
height="37.343693"
|
||||||
|
width="40.239418"
|
||||||
|
id="rect526"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.751929;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<rect
|
||||||
|
ry="4.4701343e-07"
|
||||||
|
y="-5.2654457"
|
||||||
|
x="-286.88507"
|
||||||
|
height="15.455184"
|
||||||
|
width="43.167706"
|
||||||
|
id="rect528"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.501024;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<rect
|
||||||
|
ry="4.4701343e-07"
|
||||||
|
y="15.68337"
|
||||||
|
x="-286.88507"
|
||||||
|
height="15.455184"
|
||||||
|
width="43.167706"
|
||||||
|
id="rect530"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.501024;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<rect
|
||||||
|
ry="4.4701343e-07"
|
||||||
|
y="36.959518"
|
||||||
|
x="-286.88507"
|
||||||
|
height="15.455184"
|
||||||
|
width="43.167706"
|
||||||
|
id="rect532"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.501024;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<rect
|
||||||
|
ry="1.6213723e-06"
|
||||||
|
y="60.089264"
|
||||||
|
x="-286.65378"
|
||||||
|
height="56.057846"
|
||||||
|
width="42.705132"
|
||||||
|
id="rect534"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.949072;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<rect
|
||||||
|
ry="4.4031123e-07"
|
||||||
|
y="37.077362"
|
||||||
|
x="-382.96875"
|
||||||
|
height="15.223459"
|
||||||
|
width="92.225845"
|
||||||
|
id="rect536"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.726817;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<rect
|
||||||
|
ry="4.4031123e-07"
|
||||||
|
y="59.989784"
|
||||||
|
x="-382.96875"
|
||||||
|
height="15.223459"
|
||||||
|
width="92.225845"
|
||||||
|
id="rect538"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.726817;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<rect
|
||||||
|
ry="4.4031123e-07"
|
||||||
|
y="80.283493"
|
||||||
|
x="-382.96875"
|
||||||
|
height="15.223459"
|
||||||
|
width="92.225845"
|
||||||
|
id="rect540"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.726817;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<rect
|
||||||
|
ry="4.3543034e-07"
|
||||||
|
y="124.89404"
|
||||||
|
x="-382.88803"
|
||||||
|
height="15.054706"
|
||||||
|
width="139.2859"
|
||||||
|
id="rect554"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.888245;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:8.73001px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-311.29712"
|
||||||
|
y="-16.144287"
|
||||||
|
id="text660"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-311.29712"
|
||||||
|
y="-16.144287"
|
||||||
|
style="font-size:8.73001px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan658">Display Core API (dc/dc.h)</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:10.476px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-311.40384"
|
||||||
|
y="17.511137"
|
||||||
|
id="text664"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-311.40384"
|
||||||
|
y="17.511137"
|
||||||
|
style="font-size:10.476px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan662">Link</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-336.97806"
|
||||||
|
y="43.095863"
|
||||||
|
id="text668"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-336.97806"
|
||||||
|
y="43.095863"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan666">Hardware Sequencer API</tspan><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-336.97806"
|
||||||
|
y="48.552124"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan670">(dc/inc/hw_sequence.h)</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-337.03479"
|
||||||
|
y="68.73642"
|
||||||
|
id="text750"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-337.03479"
|
||||||
|
y="68.73642"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan748">Hardware Sequencer</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-336.98022"
|
||||||
|
y="89.209091"
|
||||||
|
id="text756"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-336.98022"
|
||||||
|
y="89.209091"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan754">Block Level API (dc/inc/hw)</tspan></text>
|
||||||
|
<g
|
||||||
|
id="g1543"
|
||||||
|
transform="matrix(0.61866289,0,0,0.61866289,-146.50941,-10.146755)">
|
||||||
|
<rect
|
||||||
|
ry="7.3007396e-07"
|
||||||
|
y="180.25436"
|
||||||
|
x="-382.5336"
|
||||||
|
height="25.241808"
|
||||||
|
width="29.376135"
|
||||||
|
id="rect542"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.528201;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-367.99722"
|
||||||
|
y="195.3941"
|
||||||
|
id="text838"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-367.99722"
|
||||||
|
y="195.3941"
|
||||||
|
style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan836">DCHUB</tspan></text>
|
||||||
|
</g>
|
||||||
|
<a
|
||||||
|
id="a1538"
|
||||||
|
transform="matrix(0.61866289,0,0,0.61866289,-154.037,-10.146755)">
|
||||||
|
<rect
|
||||||
|
ry="7.3027257e-07"
|
||||||
|
y="180.25093"
|
||||||
|
x="-339.82092"
|
||||||
|
height="25.248676"
|
||||||
|
width="28.609333"
|
||||||
|
id="rect546"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.521332;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-325.67853"
|
||||||
|
y="195.35883"
|
||||||
|
id="text842"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-325.67853"
|
||||||
|
y="195.35883"
|
||||||
|
style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan840">HUBP</tspan></text>
|
||||||
|
</a>
|
||||||
|
<g
|
||||||
|
id="g1533"
|
||||||
|
transform="matrix(0.61866289,0,0,0.61866289,-154.69251,-10.146755)">
|
||||||
|
<rect
|
||||||
|
ry="7.3027257e-07"
|
||||||
|
y="180.25093"
|
||||||
|
x="-308.59961"
|
||||||
|
height="25.248676"
|
||||||
|
width="28.609333"
|
||||||
|
id="rect844"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.521332;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-294.45721"
|
||||||
|
y="195.3941"
|
||||||
|
id="text848"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-294.45721"
|
||||||
|
y="195.3941"
|
||||||
|
style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan846">DPP</tspan></text>
|
||||||
|
</g>
|
||||||
|
<g
|
||||||
|
id="g1528"
|
||||||
|
transform="matrix(0.61866289,0,0,0.61866289,-155.67539,-10.146755)">
|
||||||
|
<rect
|
||||||
|
ry="7.3027257e-07"
|
||||||
|
y="180.25093"
|
||||||
|
x="-276.84912"
|
||||||
|
height="25.248676"
|
||||||
|
width="28.609333"
|
||||||
|
id="rect850"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.521332;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-262.77728"
|
||||||
|
y="195.3941"
|
||||||
|
id="text854"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-262.77728"
|
||||||
|
y="195.3941"
|
||||||
|
style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan852">MPC</tspan></text>
|
||||||
|
</g>
|
||||||
|
<g
|
||||||
|
id="g1523"
|
||||||
|
transform="matrix(0.61866289,0,0,0.61866289,-157.64019,-10.146755)">
|
||||||
|
<rect
|
||||||
|
ry="7.3027257e-07"
|
||||||
|
y="180.25093"
|
||||||
|
x="-243.51147"
|
||||||
|
height="25.248676"
|
||||||
|
width="28.609333"
|
||||||
|
id="rect856"
|
||||||
|
style="fill:none;stroke:#000000;stroke-width:0.521332;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
|
||||||
|
x="-229.2068"
|
||||||
|
y="193.25275"
|
||||||
|
id="text860"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-229.2068"
|
||||||
|
y="193.25275"
|
||||||
|
style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583"
|
||||||
|
id="tspan858">...</tspan></text>
|
||||||
|
</g>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-313.35858"
|
||||||
|
y="133.55629"
|
||||||
|
id="text951"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-313.35858"
|
||||||
|
y="133.55629"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan949">Hardware Registers</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-265.39505"
|
||||||
|
y="86.926537"
|
||||||
|
id="text1044"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-265.39505"
|
||||||
|
y="86.926537"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan1042">DMUB</tspan><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-265.39505"
|
||||||
|
y="92.382797"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan1046">Block</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-265.42343"
|
||||||
|
y="43.272846"
|
||||||
|
id="text1052"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-265.42343"
|
||||||
|
y="43.272846"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan1048">DMUB Hardware API</tspan><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-265.42343"
|
||||||
|
y="48.729107"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan1050">(dmub/dmub_srv.h)</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-265.40161"
|
||||||
|
y="24.997644"
|
||||||
|
id="text1058"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-265.40161"
|
||||||
|
y="24.997644"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan1056">DMUB Service</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688"
|
||||||
|
x="-265.30121"
|
||||||
|
y="0.99768418"
|
||||||
|
id="text1064"><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-265.30121"
|
||||||
|
y="0.99768418"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan1062">DMUB Service API</tspan><tspan
|
||||||
|
sodipodi:role="line"
|
||||||
|
x="-265.30121"
|
||||||
|
y="6.4539466"
|
||||||
|
style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688"
|
||||||
|
id="tspan1066">(dc/dc_dmub_srv.h)</tspan></text>
|
||||||
|
</g>
|
||||||
|
</svg>
|
||||||
|
After Width: | Height: | Size: 29 KiB |
@@ -2,6 +2,181 @@
|
|||||||
Display Core Debug tools
|
Display Core Debug tools
|
||||||
========================
|
========================
|
||||||
|
|
||||||
|
In this section, you will find helpful information on debugging the amdgpu
|
||||||
|
driver from the display perspective. This page introduces debug mechanisms and
|
||||||
|
procedures to help you identify if some issues are related to display code.
|
||||||
|
|
||||||
|
Narrow down display issues
|
||||||
|
==========================
|
||||||
|
|
||||||
|
Since the display is the driver's visual component, it is common to see users
|
||||||
|
reporting issues as a display when another component causes the problem. This
|
||||||
|
section equips users to determine if a specific issue was caused by the display
|
||||||
|
component or another part of the driver.
|
||||||
|
|
||||||
|
DC dmesg important messages
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
The dmesg log is the first source of information to be checked, and amdgpu
|
||||||
|
takes advantage of this feature by logging some valuable information. When
|
||||||
|
looking for the issues associated with amdgpu, remember that each component of
|
||||||
|
the driver (e.g., smu, PSP, dm, etc.) is loaded one by one, and this
|
||||||
|
information can be found in the dmesg log. In this sense, look for the part of
|
||||||
|
the log that looks like the below log snippet::
|
||||||
|
|
||||||
|
[ 4.254295] [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x744C 0x1002:0x0E3B 0xC8).
|
||||||
|
[ 4.254718] [drm] register mmio base: 0xFCB00000
|
||||||
|
[ 4.254918] [drm] register mmio size: 1048576
|
||||||
|
[ 4.260095] [drm] add ip block number 0 <soc21_common>
|
||||||
|
[ 4.260318] [drm] add ip block number 1 <gmc_v11_0>
|
||||||
|
[ 4.260510] [drm] add ip block number 2 <ih_v6_0>
|
||||||
|
[ 4.260696] [drm] add ip block number 3 <psp>
|
||||||
|
[ 4.260878] [drm] add ip block number 4 <smu>
|
||||||
|
[ 4.261057] [drm] add ip block number 5 <dm>
|
||||||
|
[ 4.261231] [drm] add ip block number 6 <gfx_v11_0>
|
||||||
|
[ 4.261402] [drm] add ip block number 7 <sdma_v6_0>
|
||||||
|
[ 4.261568] [drm] add ip block number 8 <vcn_v4_0>
|
||||||
|
[ 4.261729] [drm] add ip block number 9 <jpeg_v4_0>
|
||||||
|
[ 4.261887] [drm] add ip block number 10 <mes_v11_0>
|
||||||
|
|
||||||
|
From the above example, you can see the line that reports that `<dm>`,
|
||||||
|
(**Display Manager**), was loaded, which means that display can be part of the
|
||||||
|
issue. If you do not see that line, something else might have failed before
|
||||||
|
amdgpu loads the display component, indicating that we don't have a
|
||||||
|
display issue.
|
||||||
|
|
||||||
|
After you identified that the DM was loaded correctly, you can check for the
|
||||||
|
display version of the hardware in use, which can be retrieved from the dmesg
|
||||||
|
log with the command::
|
||||||
|
|
||||||
|
dmesg | grep -i 'display core'
|
||||||
|
|
||||||
|
This command shows a message that looks like this::
|
||||||
|
|
||||||
|
[ 4.655828] [drm] Display Core v3.2.285 initialized on DCN 3.2
|
||||||
|
|
||||||
|
This message has two key pieces of information:
|
||||||
|
|
||||||
|
* **The DC version (e.g., v3.2.285)**: Display developers release a new DC version
|
||||||
|
every week, and this information can be advantageous in a situation where a
|
||||||
|
user/developer must find a good point versus a bad point based on a tested
|
||||||
|
version of the display code. Remember from page :ref:`Display Core <amdgpu-display-core>`,
|
||||||
|
that every week the new patches for display are heavily tested with IGT and
|
||||||
|
manual tests.
|
||||||
|
* **The DCN version (e.g., DCN 3.2)**: The DCN block is associated with the
|
||||||
|
hardware generation, and the DCN version conveys the hardware generation that
|
||||||
|
the driver is currently running. This information helps to narrow down the
|
||||||
|
code debug area since each DCN version has its files in the DC folder per DCN
|
||||||
|
component (from the example, the developer might want to focus on
|
||||||
|
files/folders/functions/structs with the dcn32 label might be executed).
|
||||||
|
However, keep in mind that DC reuses code across different DCN versions; for
|
||||||
|
example, it is expected to have some callbacks set in one DCN that are the same
|
||||||
|
as those from another DCN. In summary, use the DCN version just as a guide.
|
||||||
|
|
||||||
|
From the dmesg file, it is also possible to get the ATOM bios code by using::
|
||||||
|
|
||||||
|
dmesg | grep -i 'ATOM BIOS'
|
||||||
|
|
||||||
|
Which generates an output that looks like this::
|
||||||
|
|
||||||
|
[ 4.274534] amdgpu: ATOM BIOS: 113-D7020100-102
|
||||||
|
|
||||||
|
This type of information is useful to be reported.
|
||||||
|
|
||||||
|
Avoid loading display core
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
Sometimes, it might be hard to figure out which part of the driver is causing
|
||||||
|
the issue; if you suspect that the display is not part of the problem and your
|
||||||
|
bug scenario is simple (e.g., some desktop configuration) you can try to remove
|
||||||
|
the display component from the equation. First, you need to identify `dm` ID
|
||||||
|
from the dmesg log; for example, search for the following log::
|
||||||
|
|
||||||
|
[ 4.254295] [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x744C 0x1002:0x0E3B 0xC8).
|
||||||
|
[..]
|
||||||
|
[ 4.260095] [drm] add ip block number 0 <soc21_common>
|
||||||
|
[ 4.260318] [drm] add ip block number 1 <gmc_v11_0>
|
||||||
|
[..]
|
||||||
|
[ 4.261057] [drm] add ip block number 5 <dm>
|
||||||
|
|
||||||
|
Notice from the above example that the `dm` id is 5 for this specific hardware.
|
||||||
|
Next, you need to run the following binary operation to identify the IP block
|
||||||
|
mask::
|
||||||
|
|
||||||
|
0xffffffff & ~(1 << [DM ID])
|
||||||
|
|
||||||
|
From our example the IP mask is::
|
||||||
|
|
||||||
|
0xffffffff & ~(1 << 5) = 0xffffffdf
|
||||||
|
|
||||||
|
Finally, to disable DC, you just need to set the below parameter in your
|
||||||
|
bootloader::
|
||||||
|
|
||||||
|
amdgpu.ip_block_mask = 0xffffffdf
|
||||||
|
|
||||||
|
If you can boot your system with the DC disabled and still see the issue, it
|
||||||
|
means you can rule DC out of the equation. However, if the bug disappears, you
|
||||||
|
still need to consider the DC part of the problem and keep narrowing down the
|
||||||
|
issue. In some scenarios, disabling DC is impossible since it might be
|
||||||
|
necessary to use the display component to reproduce the issue (e.g., play a
|
||||||
|
game).
|
||||||
|
|
||||||
|
**Note: This will probably lead to the absence of a display output.**
|
||||||
|
|
||||||
|
Display flickering
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Display flickering might have multiple causes; one is the lack of proper power
|
||||||
|
to the GPU or problems in the DPM switches. A good first generic verification
|
||||||
|
is to set the GPU to use high voltage::
|
||||||
|
|
||||||
|
bash -c "echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level"
|
||||||
|
|
||||||
|
The above command sets the GPU/APU to use the maximum power allowed which
|
||||||
|
disables DPM switches. If forcing DPM levels high does not fix the issue, it
|
||||||
|
is less likely that the issue is related to power management. If the issue
|
||||||
|
disappears, there is a good chance that other components might be involved, and
|
||||||
|
the display should not be ignored since this could be a DPM issues. From the
|
||||||
|
display side, if the power increase fixes the issue, it is worth debugging the
|
||||||
|
clock configuration and the pipe split police used in the specific
|
||||||
|
configuration.
|
||||||
|
|
||||||
|
Display artifacts
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Users may see some screen artifacts that can be categorized into two different
|
||||||
|
types: localized artifacts and general artifacts. The localized artifacts
|
||||||
|
happen in some specific areas, such as around the UI window corners; if you see
|
||||||
|
this type of issue, there is a considerable chance that you have a userspace
|
||||||
|
problem, likely Mesa or similar. The general artifacts usually happen on the
|
||||||
|
entire screen. They might be caused by a misconfiguration at the driver level
|
||||||
|
of the display parameters, but the userspace might also cause this issue. One
|
||||||
|
way to identify the source of the problem is to take a screenshot or make a
|
||||||
|
desktop video capture when the problem happens; after checking the
|
||||||
|
screenshot/video recording, if you don't see any of the artifacts, it means
|
||||||
|
that the issue is likely on the the driver side. If you can still see the
|
||||||
|
problem in the data collected, it is an issue that probably happened during
|
||||||
|
rendering, and the display code just got the framebuffer already corrupted.
|
||||||
|
|
||||||
|
Disabling/Enabling specific features
|
||||||
|
====================================
|
||||||
|
|
||||||
|
DC has a struct named `dc_debug_options`, which is statically initialized by
|
||||||
|
all DCE/DCN components based on the specific hardware characteristic. This
|
||||||
|
structure usually facilitates the bring-up phase since developers can start
|
||||||
|
with many disabled features and enable them individually. This is also an
|
||||||
|
important debug feature since users can change it when debugging specific
|
||||||
|
issues.
|
||||||
|
|
||||||
|
For example, dGPU users sometimes see a problem where a horizontal fillet of
|
||||||
|
flickering happens in some specific part of the screen. This could be an
|
||||||
|
indication of Sub-Viewport issues; after the users identified the target DCN,
|
||||||
|
they can set the `force_disable_subvp` field to true in the statically
|
||||||
|
initialized version of `dc_debug_options` to see if the issue gets fixed. Along
|
||||||
|
the same lines, users/developers can also try to turn off `fams2_config` and
|
||||||
|
`enable_single_display_2to1_odm_policy`. In summary, the `dc_debug_options` is
|
||||||
|
an interesting form for identifying the problem.
|
||||||
|
|
||||||
DC Visual Confirmation
|
DC Visual Confirmation
|
||||||
======================
|
======================
|
||||||
|
|
||||||
@@ -76,6 +251,18 @@ change in real-time by using something like::
|
|||||||
When reporting a bug related to DC, consider attaching this log before and
|
When reporting a bug related to DC, consider attaching this log before and
|
||||||
after you reproduce the bug.
|
after you reproduce the bug.
|
||||||
|
|
||||||
|
Collect Firmware information
|
||||||
|
============================
|
||||||
|
|
||||||
|
When reporting issues, it is important to have the firmware information since
|
||||||
|
it can be helpful for debugging purposes. To get all the firmware information,
|
||||||
|
use the command::
|
||||||
|
|
||||||
|
cat /sys/kernel/debug/dri/0/amdgpu_firmware_info
|
||||||
|
|
||||||
|
From the display perspective, pay attention to the firmware of the DMCU and
|
||||||
|
DMCUB.
|
||||||
|
|
||||||
DMUB Firmware Debug
|
DMUB Firmware Debug
|
||||||
===================
|
===================
|
||||||
|
|
||||||
|
|||||||
@@ -1,3 +1,5 @@
|
|||||||
|
.. _dcn_blocks:
|
||||||
|
|
||||||
==========
|
==========
|
||||||
DCN Blocks
|
DCN Blocks
|
||||||
==========
|
==========
|
||||||
|
|||||||
@@ -1,3 +1,5 @@
|
|||||||
|
.. _dcn_overview:
|
||||||
|
|
||||||
=======================
|
=======================
|
||||||
Display Core Next (DCN)
|
Display Core Next (DCN)
|
||||||
=======================
|
=======================
|
||||||
|
|||||||
@@ -90,6 +90,7 @@ table of content:
|
|||||||
display-manager.rst
|
display-manager.rst
|
||||||
dcn-overview.rst
|
dcn-overview.rst
|
||||||
dcn-blocks.rst
|
dcn-blocks.rst
|
||||||
|
programming-model-dcn.rst
|
||||||
mpo-overview.rst
|
mpo-overview.rst
|
||||||
dc-debug.rst
|
dc-debug.rst
|
||||||
display-contributing.rst
|
display-contributing.rst
|
||||||
|
|||||||
162
Documentation/gpu/amdgpu/display/programming-model-dcn.rst
Normal file
162
Documentation/gpu/amdgpu/display/programming-model-dcn.rst
Normal file
@@ -0,0 +1,162 @@
|
|||||||
|
====================
|
||||||
|
DC Programming Model
|
||||||
|
====================
|
||||||
|
|
||||||
|
In the :ref:`Display Core Next (DCN) <dcn_overview>` and :ref:`DCN Block
|
||||||
|
<dcn_blocks>` pages, you learned about the hardware components and how they
|
||||||
|
interact with each other. On this page, the focus is shifted to the display
|
||||||
|
code architecture. Hence, it is reasonable to remind the reader that the code
|
||||||
|
in DC is shared with other OSes; for this reason, DC provides a set of
|
||||||
|
abstractions and operations to connect different APIs with the hardware
|
||||||
|
configuration. See DC as a service available for a Display Manager (amdgpu_dm)
|
||||||
|
to access and configure DCN/DCE hardware (DCE is also part of DC, but for
|
||||||
|
simplicity's sake, this documentation only examines DCN).
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
For this page, we will use the term GPU to refers to dGPU and APU.
|
||||||
|
|
||||||
|
Overview
|
||||||
|
========
|
||||||
|
|
||||||
|
From the display hardware perspective, it is plausible to expect that if a
|
||||||
|
problem is well-defined, it will probably be implemented at the hardware level.
|
||||||
|
On the other hand, when there are multiple ways of achieving something without
|
||||||
|
a very well-defined scope, the solution is usually implemented as a policy at
|
||||||
|
the DC level. In other words, some policies are defined in the DC core
|
||||||
|
(resource management, power optimization, image quality, etc.), and the others
|
||||||
|
implemented in hardware are enabled via DC configuration.
|
||||||
|
|
||||||
|
In terms of hardware management, DCN has multiple instances of the same block
|
||||||
|
(e.g., HUBP, DPP, MPC, etc), and during the driver execution, it might be
|
||||||
|
necessary to use some of these instances. The core has policies in place for
|
||||||
|
handling those instances. Regarding resource management, the DC objective is
|
||||||
|
quite simple: minimize the hardware shuffle when the driver performs some
|
||||||
|
actions. When the state changes from A to B, the transition is considered
|
||||||
|
easier to maneuver if the hardware resource is still used for the same set of
|
||||||
|
driver objects. Usually, adding and removing a resource to a `pipe_ctx` (more
|
||||||
|
details below) is not a problem; however, moving a resource from one `pipe_ctx`
|
||||||
|
to another should be avoided.
|
||||||
|
|
||||||
|
Another area of influence for DC is power optimization, which has a myriad of
|
||||||
|
arrangement possibilities. In some way, just displaying an image via DCN should
|
||||||
|
be relatively straightforward; however, showing it with the best power
|
||||||
|
footprint is more desirable, but it has many associated challenges.
|
||||||
|
Unfortunately, there is no straight-forward analytic way to determine if a
|
||||||
|
configuration is the best one for the context due to the enormous variety of
|
||||||
|
variables related to this problem (e.g., many different DCN/DCE hardware
|
||||||
|
versions, different displays configurations, etc.) for this reason DC
|
||||||
|
implements a dedicated library for trying some configuration and verify if it
|
||||||
|
is possible to support it or not. This type of policy is extremely complex to
|
||||||
|
create and maintain, and amdgpu driver relies on Display Mode Library (DML) to
|
||||||
|
generate the best decisions.
|
||||||
|
|
||||||
|
In summary, DC must deal with the complexity of handling multiple scenarios and
|
||||||
|
determine policies to manage them. All of the above information is conveyed to
|
||||||
|
give the reader some idea about the complexity of driving a display from the
|
||||||
|
driver's perspective. This page hopes to allow the reader to better navigate
|
||||||
|
over the amdgpu display code.
|
||||||
|
|
||||||
|
Display Driver Architecture Overview
|
||||||
|
====================================
|
||||||
|
|
||||||
|
The diagram below provides an overview of the display driver architecture;
|
||||||
|
notice it illustrates the software layers adopted by DC:
|
||||||
|
|
||||||
|
.. kernel-figure:: dc-components.svg
|
||||||
|
|
||||||
|
The first layer of the diagram is the high-level DC API represented by the
|
||||||
|
`dc.h` file; below it are two big blocks represented by Core and Link. Next is
|
||||||
|
the hardware configuration block; the main file describing it is
|
||||||
|
the`hw_sequencer.h`, where the implementation of the callbacks can be found in
|
||||||
|
the hardware sequencer folder. Almost at the end, you can see the block level
|
||||||
|
API (`dc/inc/hw`), which represents each DCN low-level block, such as HUBP,
|
||||||
|
DPP, MPC, OPTC, etc. Notice on the left side of the diagram that we have a
|
||||||
|
different set of layers representing the interaction with the DMUB
|
||||||
|
microcontroller.
|
||||||
|
|
||||||
|
Basic Objects
|
||||||
|
-------------
|
||||||
|
|
||||||
|
The below diagram outlines the basic display objects. In particular, pay
|
||||||
|
attention to the names in the boxes since they represent a data structure in
|
||||||
|
the driver:
|
||||||
|
|
||||||
|
.. kernel-figure:: dc-arch-overview.svg
|
||||||
|
|
||||||
|
Let's start with the central block in the image, `dc`. The `dc` struct is
|
||||||
|
initialized per GPU; for example, one GPU has one `dc` instance, two GPUs have
|
||||||
|
two `dc` instances, and so forth. In other words we have one 'dc' per 'amdgpu'
|
||||||
|
instance. In some ways, this object behaves like the `Singleton` pattern.
|
||||||
|
|
||||||
|
After the `dc` block in the diagram, you can see the `dc_link` component, which
|
||||||
|
is a low-level abstraction for the connector. One interesting aspect of the
|
||||||
|
image is that connectors are not part of the DCN block; they are defined by the
|
||||||
|
platform/board and not by the SoC. The `dc_link` struct is the high-level data
|
||||||
|
container with information such as connected sinks, connection status, signal
|
||||||
|
types, etc. After `dc_link`, there is the `dc_sink`, which is the object that
|
||||||
|
represents the connected display.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
For historical reasons, we used the name `dc_link`, which gives the
|
||||||
|
wrong impression that this abstraction only deals with physical connections
|
||||||
|
that the developer can easily manipulate. However, this also covers
|
||||||
|
conections like eDP or cases where the output is connected to other devices.
|
||||||
|
|
||||||
|
There are two structs that are not represented in the diagram since they were
|
||||||
|
elaborated in the DCN overview page (check the DCN block diagram :ref:`Display
|
||||||
|
Core Next (DCN) <dcn_overview>`); still, it is worth bringing back for this
|
||||||
|
overview which is `dc_stream` and `dc_state`. The `dc_stream` stores many
|
||||||
|
properties associated with the data transmission, but most importantly, it
|
||||||
|
represents the data flow from the connector to the display. Next we have
|
||||||
|
`dc_state`, which represents the logic state within the hardware at the moment;
|
||||||
|
`dc_state` is composed of `dc_stream` and `dc_plane`. The `dc_stream` is the DC
|
||||||
|
version of `drm_crtc` and represents the post-blending pipeline.
|
||||||
|
|
||||||
|
Speaking of the `dc_plane` data structure (first part of the diagram), you can
|
||||||
|
think about it as an abstraction similar to `drm_plane` that represents the
|
||||||
|
pre-blending portion of the pipeline. This image was probably processed by GFX
|
||||||
|
and is ready to be composited under a `dc_stream`. Normally, the driver may
|
||||||
|
have one or more `dc_plane` connected to the same `dc_stream`, which defines a
|
||||||
|
composition at the DC level.
|
||||||
|
|
||||||
|
Basic Operations
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Now that we have covered the basic objects, it is time to examine some of the
|
||||||
|
basic hardware/software operations. Let's start with the `dc_create()`
|
||||||
|
function, which directly works with the `dc` data struct; this function behaves
|
||||||
|
like a constructor responsible for the basic software initialization and
|
||||||
|
preparing for enabling other parts of the API. It is important to highlight
|
||||||
|
that this operation does not touch any hardware configuration; it is only a
|
||||||
|
software initialization.
|
||||||
|
|
||||||
|
Next, we have the `dc_hardware_init()`, which also relies on the `dc` data
|
||||||
|
struct. Its main function is to put the hardware in a valid state. It is worth
|
||||||
|
highlighting that the hardware might initialize in an unknown state, and it is
|
||||||
|
a requirement to put it in a valid state; this function has multiple callbacks
|
||||||
|
for the hardware-specific initialization, whereas `dc_hardware_init` does the
|
||||||
|
hardware initialization and is the first point where we touch hardware.
|
||||||
|
|
||||||
|
The `dc_get_link_at_index` is an operation that depends on the `dc_link` data
|
||||||
|
structure. This function retrieves and enumerates all the `dc_links` available
|
||||||
|
on the device; this is required since this information is not part of the SoC
|
||||||
|
definition but depends on the board configuration. As soon as the `dc_link` is
|
||||||
|
initialized, it is useful to figure out if any of them are already connected to
|
||||||
|
the display by using the `dc_link_detect()` function. After the driver figures
|
||||||
|
out if any display is connected to the device, the challenging phase starts:
|
||||||
|
configuring the monitor to show something. Nonetheless, dealing with the ideal
|
||||||
|
configuration is not a DC task since this is the Display Manager (`amdgpu_dm`)
|
||||||
|
responsibility which in turn is responsible for dealing with the atomic
|
||||||
|
commits. The only interface DC provides to the configuration phase is the
|
||||||
|
function `dc_validate_with_context` that receives the configuration information
|
||||||
|
and, based on that, validates whether the hardware can support it or not. It is
|
||||||
|
important to add that even if the display supports some specific configuration,
|
||||||
|
it does not mean the DCN hardware can support it.
|
||||||
|
|
||||||
|
After the DM and DC agree upon the configuration, the stream configuration
|
||||||
|
phase starts. This task activates one or more `dc_stream` at this phase, and in
|
||||||
|
the best-case scenario, you might be able to turn the display on with a black
|
||||||
|
screen (it does not show anything yet since it does not have any plane
|
||||||
|
associated with it). The final step would be to call the
|
||||||
|
`dc_update_planes_and_stream,` which will add or remove planes.
|
||||||
|
|
||||||
@@ -68,19 +68,25 @@ known to behave unreliably. These tests won't cause a job to fail regardless of
|
|||||||
the result. They will still be run.
|
the result. They will still be run.
|
||||||
|
|
||||||
Each new flake entry must be associated with a link to the email reporting the
|
Each new flake entry must be associated with a link to the email reporting the
|
||||||
bug to the author of the affected driver, the board name or Device Tree name of
|
bug to the author of the affected driver or the relevant GitLab issue. The entry
|
||||||
the board, the first kernel version affected, the IGT version used for tests,
|
must also include the board name or Device Tree name, the first kernel version
|
||||||
and an approximation of the failure rate.
|
affected, the IGT version used for tests, and an approximation of the failure rate.
|
||||||
|
|
||||||
They should be provided under the following format::
|
They should be provided under the following format::
|
||||||
|
|
||||||
# Bug Report: $LORE_OR_PATCHWORK_URL
|
# Bug Report: $LORE_URL_OR_GITLAB_ISSUE
|
||||||
# Board Name: broken-board.dtb
|
# Board Name: broken-board.dtb
|
||||||
# Linux Version: 6.6-rc1
|
# Linux Version: 6.6-rc1
|
||||||
# IGT Version: 1.28-gd2af13d9f
|
# IGT Version: 1.28-gd2af13d9f
|
||||||
# Failure Rate: 100
|
# Failure Rate: 100
|
||||||
flaky-test
|
flaky-test
|
||||||
|
|
||||||
|
Use the appropriate link below to create a GitLab issue:
|
||||||
|
amdgpu driver: https://gitlab.freedesktop.org/drm/amd/-/issues
|
||||||
|
i915 driver: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues
|
||||||
|
msm driver: https://gitlab.freedesktop.org/drm/msm/-/issues
|
||||||
|
xe driver: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues
|
||||||
|
|
||||||
drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
|
drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
|
||||||
-----------------------------------------------------------
|
-----------------------------------------------------------
|
||||||
|
|
||||||
|
|||||||
@@ -22,6 +22,8 @@ GPU Driver Documentation
|
|||||||
afbc
|
afbc
|
||||||
komeda-kms
|
komeda-kms
|
||||||
panfrost
|
panfrost
|
||||||
|
panthor
|
||||||
|
zynqmp
|
||||||
|
|
||||||
.. only:: subproject and html
|
.. only:: subproject and html
|
||||||
|
|
||||||
|
|||||||
@@ -13,3 +13,6 @@ Kernel clients
|
|||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_client_modeset.c
|
.. kernel-doc:: drivers/gpu/drm/drm_client_modeset.c
|
||||||
:export:
|
:export:
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/drm_client_event.c
|
||||||
|
:export:
|
||||||
|
|||||||
@@ -75,18 +75,6 @@ Module Initialization
|
|||||||
.. kernel-doc:: include/drm/drm_module.h
|
.. kernel-doc:: include/drm/drm_module.h
|
||||||
:doc: overview
|
:doc: overview
|
||||||
|
|
||||||
Managing Ownership of the Framebuffer Aperture
|
|
||||||
----------------------------------------------
|
|
||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
|
|
||||||
:doc: overview
|
|
||||||
|
|
||||||
.. kernel-doc:: include/drm/drm_aperture.h
|
|
||||||
:internal:
|
|
||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
|
|
||||||
:export:
|
|
||||||
|
|
||||||
Device Instance and Driver Handling
|
Device Instance and Driver Handling
|
||||||
-----------------------------------
|
-----------------------------------
|
||||||
|
|
||||||
|
|||||||
@@ -110,15 +110,6 @@ fbdev Helper Functions Reference
|
|||||||
.. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c
|
.. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c
|
||||||
:doc: fbdev helpers
|
:doc: fbdev helpers
|
||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_fbdev_dma.c
|
|
||||||
:export:
|
|
||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_fbdev_shmem.c
|
|
||||||
:export:
|
|
||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_fbdev_ttm.c
|
|
||||||
:export:
|
|
||||||
|
|
||||||
.. kernel-doc:: include/drm/drm_fb_helper.h
|
.. kernel-doc:: include/drm/drm_fb_helper.h
|
||||||
:internal:
|
:internal:
|
||||||
|
|
||||||
@@ -181,7 +172,7 @@ Bridge Operations
|
|||||||
Bridge Connector Helper
|
Bridge Connector Helper
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c
|
.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c
|
||||||
:doc: overview
|
:doc: overview
|
||||||
|
|
||||||
|
|
||||||
@@ -204,7 +195,7 @@ MIPI-DSI bridge operation
|
|||||||
Bridge Connector Helper Reference
|
Bridge Connector Helper Reference
|
||||||
---------------------------------
|
---------------------------------
|
||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c
|
.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c
|
||||||
:export:
|
:export:
|
||||||
|
|
||||||
Panel-Bridge Helper Reference
|
Panel-Bridge Helper Reference
|
||||||
|
|||||||
@@ -305,13 +305,26 @@ Kernel Mode Driver
|
|||||||
------------------
|
------------------
|
||||||
|
|
||||||
The KMD is responsible for checking if the device needs a reset, and to perform
|
The KMD is responsible for checking if the device needs a reset, and to perform
|
||||||
it as needed. Usually a hang is detected when a job gets stuck executing. KMD
|
it as needed. Usually a hang is detected when a job gets stuck executing.
|
||||||
should keep track of resets, because userspace can query any time about the
|
|
||||||
reset status for a specific context. This is needed to propagate to the rest of
|
Propagation of errors to userspace has proven to be tricky since it goes in
|
||||||
the stack that a reset has happened. Currently, this is implemented by each
|
the opposite direction of the usual flow of commands. Because of this vendor
|
||||||
driver separately, with no common DRM interface. Ideally this should be properly
|
independent error handling was added to the &dma_fence object, this way drivers
|
||||||
integrated at DRM scheduler to provide a common ground for all drivers. After a
|
can add an error code to their fences before signaling them. See function
|
||||||
reset, KMD should reject new command submissions for affected contexts.
|
dma_fence_set_error() on how to do this and for examples of error codes to use.
|
||||||
|
|
||||||
|
The DRM scheduler also allows setting error codes on all pending fences when
|
||||||
|
hardware submissions are restarted after an reset. Error codes are also
|
||||||
|
forwarded from the hardware fence to the scheduler fence to bubble up errors
|
||||||
|
to the higher levels of the stack and eventually userspace.
|
||||||
|
|
||||||
|
Fence errors can be queried by userspace through the generic SYNC_IOC_FILE_INFO
|
||||||
|
IOCTL as well as through driver specific interfaces.
|
||||||
|
|
||||||
|
Additional to setting fence errors drivers should also keep track of resets per
|
||||||
|
context, the DRM scheduler provides the drm_sched_entity_error() function as
|
||||||
|
helper for this use case. After a reset, KMD should reject new command
|
||||||
|
submissions for affected contexts.
|
||||||
|
|
||||||
User Mode Driver
|
User Mode Driver
|
||||||
----------------
|
----------------
|
||||||
|
|||||||
@@ -73,6 +73,11 @@ scope of each device, in which case `drm-pdev` shall be present as well.
|
|||||||
Userspace should make sure to not double account any usage statistics by using
|
Userspace should make sure to not double account any usage statistics by using
|
||||||
the above described criteria in order to associate data to individual clients.
|
the above described criteria in order to associate data to individual clients.
|
||||||
|
|
||||||
|
- drm-client-name: <valstr>
|
||||||
|
|
||||||
|
String optionally set by userspace using DRM_IOCTL_SET_CLIENT_NAME.
|
||||||
|
|
||||||
|
|
||||||
Utilization
|
Utilization
|
||||||
^^^^^^^^^^^
|
^^^^^^^^^^^
|
||||||
|
|
||||||
@@ -144,7 +149,9 @@ Memory
|
|||||||
|
|
||||||
Each possible memory type which can be used to store buffer objects by the
|
Each possible memory type which can be used to store buffer objects by the
|
||||||
GPU in question shall be given a stable and unique name to be returned as the
|
GPU in question shall be given a stable and unique name to be returned as the
|
||||||
string here. The name "memory" is reserved to refer to normal system memory.
|
string here.
|
||||||
|
|
||||||
|
The region name "memory" is reserved to refer to normal system memory.
|
||||||
|
|
||||||
Value shall reflect the amount of storage currently consumed by the buffer
|
Value shall reflect the amount of storage currently consumed by the buffer
|
||||||
objects belong to this client, in the respective memory region.
|
objects belong to this client, in the respective memory region.
|
||||||
@@ -152,6 +159,9 @@ objects belong to this client, in the respective memory region.
|
|||||||
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
|
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
|
||||||
indicating kibi- or mebi-bytes.
|
indicating kibi- or mebi-bytes.
|
||||||
|
|
||||||
|
This key is deprecated and is an alias for drm-resident-<region>. Only one of
|
||||||
|
the two should be present in the output.
|
||||||
|
|
||||||
- drm-shared-<region>: <uint> [KiB|MiB]
|
- drm-shared-<region>: <uint> [KiB|MiB]
|
||||||
|
|
||||||
The total size of buffers that are shared with another file (e.g., have more
|
The total size of buffers that are shared with another file (e.g., have more
|
||||||
@@ -159,20 +169,34 @@ than a single handle).
|
|||||||
|
|
||||||
- drm-total-<region>: <uint> [KiB|MiB]
|
- drm-total-<region>: <uint> [KiB|MiB]
|
||||||
|
|
||||||
The total size of buffers that including shared and private memory.
|
The total size of all created buffers including shared and private memory. The
|
||||||
|
backing store for the buffers does not have to be currently instantiated to be
|
||||||
|
counted under this category.
|
||||||
|
|
||||||
- drm-resident-<region>: <uint> [KiB|MiB]
|
- drm-resident-<region>: <uint> [KiB|MiB]
|
||||||
|
|
||||||
The total size of buffers that are resident in the specified region.
|
The total size of buffers that are resident (have their backing store present or
|
||||||
|
instantiated) in the specified region.
|
||||||
|
|
||||||
|
This is an alias for drm-memory-<region> and only one of the two should be
|
||||||
|
present in the output.
|
||||||
|
|
||||||
- drm-purgeable-<region>: <uint> [KiB|MiB]
|
- drm-purgeable-<region>: <uint> [KiB|MiB]
|
||||||
|
|
||||||
The total size of buffers that are purgeable.
|
The total size of buffers that are purgeable.
|
||||||
|
|
||||||
|
For example drivers which implement a form of 'madvise' like functionality can
|
||||||
|
here count buffers which have instantiated backing store, but have been marked
|
||||||
|
with an equivalent of MADV_DONTNEED.
|
||||||
|
|
||||||
- drm-active-<region>: <uint> [KiB|MiB]
|
- drm-active-<region>: <uint> [KiB|MiB]
|
||||||
|
|
||||||
The total size of buffers that are active on one or more engines.
|
The total size of buffers that are active on one or more engines.
|
||||||
|
|
||||||
|
One practical example of this can be presence of unsignaled fences in an GEM
|
||||||
|
buffer reservation object. Therefore the active category is a subset of
|
||||||
|
resident.
|
||||||
|
|
||||||
Implementation Details
|
Implementation Details
|
||||||
======================
|
======================
|
||||||
|
|
||||||
@@ -186,4 +210,5 @@ Driver specific implementations
|
|||||||
|
|
||||||
* :ref:`i915-usage-stats`
|
* :ref:`i915-usage-stats`
|
||||||
* :ref:`panfrost-usage-stats`
|
* :ref:`panfrost-usage-stats`
|
||||||
|
* :ref:`panthor-usage-stats`
|
||||||
* :ref:`xe-usage-stats`
|
* :ref:`xe-usage-stats`
|
||||||
|
|||||||
46
Documentation/gpu/panthor.rst
Normal file
46
Documentation/gpu/panthor.rst
Normal file
@@ -0,0 +1,46 @@
|
|||||||
|
.. SPDX-License-Identifier: GPL-2.0+
|
||||||
|
|
||||||
|
=========================
|
||||||
|
drm/Panthor CSF driver
|
||||||
|
=========================
|
||||||
|
|
||||||
|
.. _panthor-usage-stats:
|
||||||
|
|
||||||
|
Panthor DRM client usage stats implementation
|
||||||
|
==============================================
|
||||||
|
|
||||||
|
The drm/Panthor driver implements the DRM client usage stats specification as
|
||||||
|
documented in :ref:`drm-client-usage-stats`.
|
||||||
|
|
||||||
|
Example of the output showing the implemented key value pairs and entirety of
|
||||||
|
the currently possible format options:
|
||||||
|
|
||||||
|
::
|
||||||
|
pos: 0
|
||||||
|
flags: 02400002
|
||||||
|
mnt_id: 29
|
||||||
|
ino: 491
|
||||||
|
drm-driver: panthor
|
||||||
|
drm-client-id: 10
|
||||||
|
drm-engine-panthor: 111110952750 ns
|
||||||
|
drm-cycles-panthor: 94439687187
|
||||||
|
drm-maxfreq-panthor: 1000000000 Hz
|
||||||
|
drm-curfreq-panthor: 1000000000 Hz
|
||||||
|
drm-total-memory: 16480 KiB
|
||||||
|
drm-shared-memory: 0
|
||||||
|
drm-active-memory: 16200 KiB
|
||||||
|
drm-resident-memory: 16480 KiB
|
||||||
|
drm-purgeable-memory: 0
|
||||||
|
|
||||||
|
Possible `drm-engine-` key names are: `panthor`.
|
||||||
|
`drm-curfreq-` values convey the current operating frequency for that engine.
|
||||||
|
|
||||||
|
Users must bear in mind that engine and cycle sampling are disabled by default,
|
||||||
|
because of power saving concerns. `fdinfo` users and benchmark applications which
|
||||||
|
query the fdinfo file must make sure to toggle the job profiling status of the
|
||||||
|
driver by writing into the appropriate sysfs node::
|
||||||
|
|
||||||
|
echo <N> > /sys/bus/platform/drivers/panthor/[a-f0-9]*.gpu/profiling
|
||||||
|
|
||||||
|
Where `N` is a bit mask where cycle and timestamp sampling are respectively
|
||||||
|
enabled by the first and second bits.
|
||||||
@@ -834,6 +834,22 @@ Contact: Javier Martinez Canillas <javierm@redhat.com>
|
|||||||
|
|
||||||
Level: Advanced
|
Level: Advanced
|
||||||
|
|
||||||
|
Querying errors from drm_syncobj
|
||||||
|
================================
|
||||||
|
|
||||||
|
The drm_syncobj container can be used by driver independent code to signal
|
||||||
|
complection of submission.
|
||||||
|
|
||||||
|
One minor feature still missing is a generic DRM IOCTL to query the error
|
||||||
|
status of binary and timeline drm_syncobj.
|
||||||
|
|
||||||
|
This should probably be improved by implementing the necessary kernel interface
|
||||||
|
and adding support for that in the userspace stack.
|
||||||
|
|
||||||
|
Contact: Christian König
|
||||||
|
|
||||||
|
Level: Starter
|
||||||
|
|
||||||
Outside DRM
|
Outside DRM
|
||||||
===========
|
===========
|
||||||
|
|
||||||
|
|||||||
149
Documentation/gpu/zynqmp.rst
Normal file
149
Documentation/gpu/zynqmp.rst
Normal file
@@ -0,0 +1,149 @@
|
|||||||
|
.. SPDX-License-Identifier: GPL-2.0+
|
||||||
|
|
||||||
|
===============================================
|
||||||
|
Xilinx ZynqMP Ultrascale+ DisplayPort Subsystem
|
||||||
|
===============================================
|
||||||
|
|
||||||
|
This subsystem handles DisplayPort video and audio output on the ZynqMP. It
|
||||||
|
supports in-memory framebuffers with the DisplayPort DMA controller
|
||||||
|
(xilinx-dpdma), as well as "live" video and audio from the programmable logic
|
||||||
|
(PL). This subsystem can perform several transformations, including color space
|
||||||
|
conversion, alpha blending, and audio mixing, although not all features are
|
||||||
|
currently supported.
|
||||||
|
|
||||||
|
debugfs
|
||||||
|
-------
|
||||||
|
|
||||||
|
To support debugging and compliance testing, several test modes can be enabled
|
||||||
|
though debugfs. The following files in /sys/kernel/debug/dri/X/DP-1/test/
|
||||||
|
control the DisplayPort test modes:
|
||||||
|
|
||||||
|
active:
|
||||||
|
Writing a 1 to this file will activate test mode, and writing a 0 will
|
||||||
|
deactivate test mode. Writing a 1 or 0 when the test mode is already
|
||||||
|
active/inactive will re-activate/re-deactivate test mode. When test
|
||||||
|
mode is inactive, changes made to other files will have no (immediate)
|
||||||
|
effect, although the settings will be saved for when test mode is
|
||||||
|
activated. When test mode is active, changes made to other files will
|
||||||
|
apply immediately.
|
||||||
|
|
||||||
|
custom:
|
||||||
|
Custom test pattern value
|
||||||
|
|
||||||
|
downspread:
|
||||||
|
Enable/disable clock downspreading (spread-spectrum clocking) by
|
||||||
|
writing 1/0
|
||||||
|
|
||||||
|
enhanced:
|
||||||
|
Enable/disable enhanced framing
|
||||||
|
|
||||||
|
ignore_aux_errors:
|
||||||
|
Ignore AUX errors when set to 1. Writes to this file take effect
|
||||||
|
immediately (regardless of whether test mode is active) and affect all
|
||||||
|
AUX transfers.
|
||||||
|
|
||||||
|
ignore_hpd:
|
||||||
|
Ignore hotplug events (such as cable removals or monitor link
|
||||||
|
retraining requests) when set to 1. Writes to this file take effect
|
||||||
|
immediately (regardless of whether test mode is active).
|
||||||
|
|
||||||
|
laneX_preemphasis:
|
||||||
|
Preemphasis from 0 (lowest) to 2 (highest) for lane X
|
||||||
|
|
||||||
|
laneX_swing:
|
||||||
|
Voltage swing from 0 (lowest) to 3 (highest) for lane X
|
||||||
|
|
||||||
|
lanes:
|
||||||
|
Number of lanes to use (1, 2, or 4)
|
||||||
|
|
||||||
|
pattern:
|
||||||
|
Test pattern. May be one of:
|
||||||
|
|
||||||
|
video
|
||||||
|
Use regular video input
|
||||||
|
|
||||||
|
symbol-error
|
||||||
|
Symbol error measurement pattern
|
||||||
|
|
||||||
|
prbs7
|
||||||
|
Output of the PRBS7 (x^7 + x^6 + 1) polynomial
|
||||||
|
|
||||||
|
80bit-custom
|
||||||
|
A custom 80-bit pattern
|
||||||
|
|
||||||
|
cp2520
|
||||||
|
HBR2 compliance eye pattern
|
||||||
|
|
||||||
|
tps1
|
||||||
|
Link training symbol pattern TPS1 (/D10.2/)
|
||||||
|
|
||||||
|
tps2
|
||||||
|
Link training symbol pattern TPS2
|
||||||
|
|
||||||
|
tps3
|
||||||
|
Link training symbol pattern TPS3 (for HBR2)
|
||||||
|
|
||||||
|
rate:
|
||||||
|
Rate in hertz. One of
|
||||||
|
|
||||||
|
* 5400000000 (HBR2)
|
||||||
|
* 2700000000 (HBR)
|
||||||
|
* 1620000000 (RBR)
|
||||||
|
|
||||||
|
You can dump the displayport test settings with the following command::
|
||||||
|
|
||||||
|
for prop in /sys/kernel/debug/dri/1/DP-1/test/*; do
|
||||||
|
printf '%-17s ' ${prop##*/}
|
||||||
|
if [ ${prop##*/} = custom ]; then
|
||||||
|
hexdump -C $prop | head -1
|
||||||
|
else
|
||||||
|
cat $prop
|
||||||
|
fi
|
||||||
|
done
|
||||||
|
|
||||||
|
The output could look something like::
|
||||||
|
|
||||||
|
active 1
|
||||||
|
custom 00000000 00 00 00 00 00 00 00 00 00 00 |..........|
|
||||||
|
downspread 0
|
||||||
|
enhanced 1
|
||||||
|
ignore_aux_errors 1
|
||||||
|
ignore_hpd 1
|
||||||
|
lane0_preemphasis 0
|
||||||
|
lane0_swing 3
|
||||||
|
lane1_preemphasis 0
|
||||||
|
lane1_swing 3
|
||||||
|
lanes 2
|
||||||
|
pattern prbs7
|
||||||
|
rate 1620000000
|
||||||
|
|
||||||
|
The recommended test procedure is to connect the board to a monitor,
|
||||||
|
configure test mode, activate test mode, and then disconnect the cable
|
||||||
|
and connect it to your test equipment of choice. For example, one
|
||||||
|
sequence of commands could be::
|
||||||
|
|
||||||
|
echo 1 > /sys/kernel/debug/dri/1/DP-1/test/enhanced
|
||||||
|
echo tps1 > /sys/kernel/debug/dri/1/DP-1/test/pattern
|
||||||
|
echo 1620000000 > /sys/kernel/debug/dri/1/DP-1/test/rate
|
||||||
|
echo 1 > /sys/kernel/debug/dri/1/DP-1/test/ignore_aux_errors
|
||||||
|
echo 1 > /sys/kernel/debug/dri/1/DP-1/test/ignore_hpd
|
||||||
|
echo 1 > /sys/kernel/debug/dri/1/DP-1/test/active
|
||||||
|
|
||||||
|
at which point the cable could be disconnected from the monitor.
|
||||||
|
|
||||||
|
Internals
|
||||||
|
---------
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_disp.h
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_dpsub.h
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_kms.h
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_disp.c
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_dp.c
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_dpsub.c
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_kms.c
|
||||||
@@ -41,13 +41,22 @@ supports only 1 SDO line.
|
|||||||
Reference voltage
|
Reference voltage
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
2 possible reference voltage sources are supported:
|
ad7380-4
|
||||||
|
~~~~~~~~
|
||||||
|
|
||||||
|
ad7380-4 supports only an external reference voltage (2.5V to 3.3V). It must be
|
||||||
|
declared in the device tree as ``refin-supply``.
|
||||||
|
|
||||||
|
All other devices from ad738x family
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
All other devices from ad738x support 2 possible reference voltage sources:
|
||||||
|
|
||||||
- Internal reference (2.5V)
|
- Internal reference (2.5V)
|
||||||
- External reference (2.5V to 3.3V)
|
- External reference (2.5V to 3.3V)
|
||||||
|
|
||||||
The source is determined by the device tree. If ``refio-supply`` is present,
|
The source is determined by the device tree. If ``refio-supply`` is present,
|
||||||
then the external reference is used, else the internal reference is used.
|
then it is used as external reference, else the internal reference is used.
|
||||||
|
|
||||||
Oversampling and resolution boost
|
Oversampling and resolution boost
|
||||||
---------------------------------
|
---------------------------------
|
||||||
|
|||||||
@@ -7,26 +7,26 @@ The DAMON subsystem covers the files that are listed in 'DATA ACCESS MONITOR'
|
|||||||
section of 'MAINTAINERS' file.
|
section of 'MAINTAINERS' file.
|
||||||
|
|
||||||
The mailing lists for the subsystem are damon@lists.linux.dev and
|
The mailing lists for the subsystem are damon@lists.linux.dev and
|
||||||
linux-mm@kvack.org. Patches should be made against the mm-unstable `tree
|
linux-mm@kvack.org. Patches should be made against the `mm-unstable tree
|
||||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>` whenever possible and posted to
|
<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ whenever possible and posted
|
||||||
the mailing lists.
|
to the mailing lists.
|
||||||
|
|
||||||
SCM Trees
|
SCM Trees
|
||||||
---------
|
---------
|
||||||
|
|
||||||
There are multiple Linux trees for DAMON development. Patches under
|
There are multiple Linux trees for DAMON development. Patches under
|
||||||
development or testing are queued in `damon/next
|
development or testing are queued in `damon/next
|
||||||
<https://git.kernel.org/sj/h/damon/next>` by the DAMON maintainer.
|
<https://git.kernel.org/sj/h/damon/next>`_ by the DAMON maintainer.
|
||||||
Sufficiently reviewed patches will be queued in `mm-unstable
|
Sufficiently reviewed patches will be queued in `mm-unstable
|
||||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>` by the memory management
|
<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ by the memory management
|
||||||
subsystem maintainer. After more sufficient tests, the patches will be queued
|
subsystem maintainer. After more sufficient tests, the patches will be queued
|
||||||
in `mm-stable <https://git.kernel.org/akpm/mm/h/mm-stable>` , and finally
|
in `mm-stable <https://git.kernel.org/akpm/mm/h/mm-stable>`_, and finally
|
||||||
pull-requested to the mainline by the memory management subsystem maintainer.
|
pull-requested to the mainline by the memory management subsystem maintainer.
|
||||||
|
|
||||||
Note again the patches for mm-unstable `tree
|
Note again the patches for `mm-unstable tree
|
||||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>` are queued by the memory
|
<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ are queued by the memory
|
||||||
management subsystem maintainer. If the patches requires some patches in
|
management subsystem maintainer. If the patches requires some patches in
|
||||||
damon/next `tree <https://git.kernel.org/sj/h/damon/next>` which not yet merged
|
`damon/next tree <https://git.kernel.org/sj/h/damon/next>`_ which not yet merged
|
||||||
in mm-unstable, please make sure the requirement is clearly specified.
|
in mm-unstable, please make sure the requirement is clearly specified.
|
||||||
|
|
||||||
Submit checklist addendum
|
Submit checklist addendum
|
||||||
@@ -37,25 +37,25 @@ When making DAMON changes, you should do below.
|
|||||||
- Build changes related outputs including kernel and documents.
|
- Build changes related outputs including kernel and documents.
|
||||||
- Ensure the builds introduce no new errors or warnings.
|
- Ensure the builds introduce no new errors or warnings.
|
||||||
- Run and ensure no new failures for DAMON `selftests
|
- Run and ensure no new failures for DAMON `selftests
|
||||||
<https://github.com/awslabs/damon-tests/blob/master/corr/run.sh#L49>` and
|
<https://github.com/damonitor/damon-tests/blob/master/corr/run.sh#L49>`_ and
|
||||||
`kunittests
|
`kunittests
|
||||||
<https://github.com/awslabs/damon-tests/blob/master/corr/tests/kunit.sh>`.
|
<https://github.com/damonitor/damon-tests/blob/master/corr/tests/kunit.sh>`_.
|
||||||
|
|
||||||
Further doing below and putting the results will be helpful.
|
Further doing below and putting the results will be helpful.
|
||||||
|
|
||||||
- Run `damon-tests/corr
|
- Run `damon-tests/corr
|
||||||
<https://github.com/awslabs/damon-tests/tree/master/corr>` for normal
|
<https://github.com/damonitor/damon-tests/tree/master/corr>`_ for normal
|
||||||
changes.
|
changes.
|
||||||
- Run `damon-tests/perf
|
- Run `damon-tests/perf
|
||||||
<https://github.com/awslabs/damon-tests/tree/master/perf>` for performance
|
<https://github.com/damonitor/damon-tests/tree/master/perf>`_ for performance
|
||||||
changes.
|
changes.
|
||||||
|
|
||||||
Key cycle dates
|
Key cycle dates
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
Patches can be sent anytime. Key cycle dates of the `mm-unstable
|
Patches can be sent anytime. Key cycle dates of the `mm-unstable
|
||||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>` and `mm-stable
|
<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ and `mm-stable
|
||||||
<https://git.kernel.org/akpm/mm/h/mm-stable>` trees depend on the memory
|
<https://git.kernel.org/akpm/mm/h/mm-stable>`_ trees depend on the memory
|
||||||
management subsystem maintainer.
|
management subsystem maintainer.
|
||||||
|
|
||||||
Review cadence
|
Review cadence
|
||||||
@@ -72,13 +72,13 @@ Mailing tool
|
|||||||
Like many other Linux kernel subsystems, DAMON uses the mailing lists
|
Like many other Linux kernel subsystems, DAMON uses the mailing lists
|
||||||
(damon@lists.linux.dev and linux-mm@kvack.org) as the major communication
|
(damon@lists.linux.dev and linux-mm@kvack.org) as the major communication
|
||||||
channel. There is a simple tool called `HacKerMaiL
|
channel. There is a simple tool called `HacKerMaiL
|
||||||
<https://github.com/damonitor/hackermail>` (``hkml``), which is for people who
|
<https://github.com/damonitor/hackermail>`_ (``hkml``), which is for people who
|
||||||
are not very familiar with the mailing lists based communication. The tool
|
are not very familiar with the mailing lists based communication. The tool
|
||||||
could be particularly helpful for DAMON community members since it is developed
|
could be particularly helpful for DAMON community members since it is developed
|
||||||
and maintained by DAMON maintainer. The tool is also officially announced to
|
and maintained by DAMON maintainer. The tool is also officially announced to
|
||||||
support DAMON and general Linux kernel development workflow.
|
support DAMON and general Linux kernel development workflow.
|
||||||
|
|
||||||
In other words, `hkml <https://github.com/damonitor/hackermail>` is a mailing
|
In other words, `hkml <https://github.com/damonitor/hackermail>`_ is a mailing
|
||||||
tool for DAMON community, which DAMON maintainer is committed to support.
|
tool for DAMON community, which DAMON maintainer is committed to support.
|
||||||
Please feel free to try and report issues or feature requests for the tool to
|
Please feel free to try and report issues or feature requests for the tool to
|
||||||
the maintainer.
|
the maintainer.
|
||||||
@@ -98,8 +98,8 @@ slots, and attendees should reserve one of those at least 24 hours before the
|
|||||||
time slot, by reaching out to the maintainer.
|
time slot, by reaching out to the maintainer.
|
||||||
|
|
||||||
Schedules and available reservation time slots are available at the Google `doc
|
Schedules and available reservation time slots are available at the Google `doc
|
||||||
<https://docs.google.com/document/d/1v43Kcj3ly4CYqmAkMaZzLiM2GEnWfgdGbZAH3mi2vpM/edit?usp=sharing>`.
|
<https://docs.google.com/document/d/1v43Kcj3ly4CYqmAkMaZzLiM2GEnWfgdGbZAH3mi2vpM/edit?usp=sharing>`_.
|
||||||
There is also a public Google `calendar
|
There is also a public Google `calendar
|
||||||
<https://calendar.google.com/calendar/u/0?cid=ZDIwOTA4YTMxNjc2MDQ3NTIyMmUzYTM5ZmQyM2U4NDA0ZGIwZjBiYmJlZGQxNDM0MmY4ZTRjOTE0NjdhZDRiY0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t>`
|
<https://calendar.google.com/calendar/u/0?cid=ZDIwOTA4YTMxNjc2MDQ3NTIyMmUzYTM5ZmQyM2U4NDA0ZGIwZjBiYmJlZGQxNDM0MmY4ZTRjOTE0NjdhZDRiY0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t>`_
|
||||||
that has the events. Anyone can subscribe it. DAMON maintainer will also
|
that has the events. Anyone can subscribe it. DAMON maintainer will also
|
||||||
provide periodic reminder to the mailing list (damon@lists.linux.dev).
|
provide periodic reminder to the mailing list (damon@lists.linux.dev).
|
||||||
|
|||||||
@@ -144,9 +144,8 @@ IRQ should only be unmasked after a successful call to napi_complete_done():
|
|||||||
|
|
||||||
napi_schedule_irqoff() is a variant of napi_schedule() which takes advantage
|
napi_schedule_irqoff() is a variant of napi_schedule() which takes advantage
|
||||||
of guarantees given by being invoked in IRQ context (no need to
|
of guarantees given by being invoked in IRQ context (no need to
|
||||||
mask interrupts). Note that PREEMPT_RT forces all interrupts
|
mask interrupts). napi_schedule_irqoff() will fall back to napi_schedule() if
|
||||||
to be threaded so the interrupt may need to be marked ``IRQF_NO_THREAD``
|
IRQs are threaded (such as if ``PREEMPT_RT`` is enabled).
|
||||||
to avoid issues on real-time kernel configurations.
|
|
||||||
|
|
||||||
Instance to queue mapping
|
Instance to queue mapping
|
||||||
-------------------------
|
-------------------------
|
||||||
|
|||||||
@@ -16,7 +16,7 @@ ii) transmit network traffic, or any other that needs raw
|
|||||||
|
|
||||||
Howto can be found at:
|
Howto can be found at:
|
||||||
|
|
||||||
https://sites.google.com/site/packetmmap/
|
https://web.archive.org/web/20220404160947/https://sites.google.com/site/packetmmap/
|
||||||
|
|
||||||
Please send your comments to
|
Please send your comments to
|
||||||
- Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
|
- Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
|
||||||
@@ -166,7 +166,8 @@ As capture, each frame contains two parts::
|
|||||||
/* bind socket to eth0 */
|
/* bind socket to eth0 */
|
||||||
bind(this->socket, (struct sockaddr *)&my_addr, sizeof(struct sockaddr_ll));
|
bind(this->socket, (struct sockaddr *)&my_addr, sizeof(struct sockaddr_ll));
|
||||||
|
|
||||||
A complete tutorial is available at: https://sites.google.com/site/packetmmap/
|
A complete tutorial is available at:
|
||||||
|
https://web.archive.org/web/20220404160947/https://sites.google.com/site/packetmmap/
|
||||||
|
|
||||||
By default, the user should put data at::
|
By default, the user should put data at::
|
||||||
|
|
||||||
|
|||||||
@@ -9,7 +9,7 @@ segments between trusted peers. It adds a new TCP header option with
|
|||||||
a Message Authentication Code (MAC). MACs are produced from the content
|
a Message Authentication Code (MAC). MACs are produced from the content
|
||||||
of a TCP segment using a hashing function with a password known to both peers.
|
of a TCP segment using a hashing function with a password known to both peers.
|
||||||
The intent of TCP-AO is to deprecate TCP-MD5 providing better security,
|
The intent of TCP-AO is to deprecate TCP-MD5 providing better security,
|
||||||
key rotation and support for variety of hashing algorithms.
|
key rotation and support for a variety of hashing algorithms.
|
||||||
|
|
||||||
1. Introduction
|
1. Introduction
|
||||||
===============
|
===============
|
||||||
@@ -164,9 +164,9 @@ A: It should not, no action needs to be performed [7.5.2.e]::
|
|||||||
is not available, no action is required (RNextKeyID of a received
|
is not available, no action is required (RNextKeyID of a received
|
||||||
segment needs to match the MKT’s SendID).
|
segment needs to match the MKT’s SendID).
|
||||||
|
|
||||||
Q: How current_key is set and when does it change? It is a user-triggered
|
Q: How is current_key set, and when does it change? Is it a user-triggered
|
||||||
change, or is it by a request from the remote peer? Is it set by the user
|
change, or is it triggered by a request from the remote peer? Is it set by the
|
||||||
explicitly, or by a matching rule?
|
user explicitly, or by a matching rule?
|
||||||
|
|
||||||
A: current_key is set by RNextKeyID [6.1]::
|
A: current_key is set by RNextKeyID [6.1]::
|
||||||
|
|
||||||
@@ -233,8 +233,8 @@ always have one current_key [3.3]::
|
|||||||
|
|
||||||
Q: Can a non-TCP-AO connection become a TCP-AO-enabled one?
|
Q: Can a non-TCP-AO connection become a TCP-AO-enabled one?
|
||||||
|
|
||||||
A: No: for already established non-TCP-AO connection it would be impossible
|
A: No: for an already established non-TCP-AO connection it would be impossible
|
||||||
to switch using TCP-AO as the traffic key generation requires the initial
|
to switch to using TCP-AO, as the traffic key generation requires the initial
|
||||||
sequence numbers. Paraphrasing, starting using TCP-AO would require
|
sequence numbers. Paraphrasing, starting using TCP-AO would require
|
||||||
re-establishing the TCP connection.
|
re-establishing the TCP connection.
|
||||||
|
|
||||||
@@ -292,7 +292,7 @@ no transparency is really needed and modern BGP daemons already have
|
|||||||
|
|
||||||
Linux provides a set of ``setsockopt()s`` and ``getsockopt()s`` that let
|
Linux provides a set of ``setsockopt()s`` and ``getsockopt()s`` that let
|
||||||
userspace manage TCP-AO on a per-socket basis. In order to add/delete MKTs
|
userspace manage TCP-AO on a per-socket basis. In order to add/delete MKTs
|
||||||
``TCP_AO_ADD_KEY`` and ``TCP_AO_DEL_KEY`` TCP socket options must be used
|
``TCP_AO_ADD_KEY`` and ``TCP_AO_DEL_KEY`` TCP socket options must be used.
|
||||||
It is not allowed to add a key on an established non-TCP-AO connection
|
It is not allowed to add a key on an established non-TCP-AO connection
|
||||||
as well as to remove the last key from TCP-AO connection.
|
as well as to remove the last key from TCP-AO connection.
|
||||||
|
|
||||||
@@ -361,7 +361,7 @@ not implemented.
|
|||||||
4. ``setsockopt()`` vs ``accept()`` race
|
4. ``setsockopt()`` vs ``accept()`` race
|
||||||
========================================
|
========================================
|
||||||
|
|
||||||
In contrast with TCP-MD5 established connection which has just one key,
|
In contrast with an established TCP-MD5 connection which has just one key,
|
||||||
TCP-AO connections may have many keys, which means that accepted connections
|
TCP-AO connections may have many keys, which means that accepted connections
|
||||||
on a listen socket may have any amount of keys as well. As copying all those
|
on a listen socket may have any amount of keys as well. As copying all those
|
||||||
keys on a first properly signed SYN would make the request socket bigger, that
|
keys on a first properly signed SYN would make the request socket bigger, that
|
||||||
@@ -374,7 +374,7 @@ keys from sockets that were already established, but not yet ``accept()``'ed,
|
|||||||
hanging in the accept queue.
|
hanging in the accept queue.
|
||||||
|
|
||||||
The reverse is valid as well: if userspace adds a new key for a peer on
|
The reverse is valid as well: if userspace adds a new key for a peer on
|
||||||
a listener socket, the established sockets in accept queue won't
|
a listener socket, the established sockets in the accept queue won't
|
||||||
have the new keys.
|
have the new keys.
|
||||||
|
|
||||||
At this moment, the resolution for the two races:
|
At this moment, the resolution for the two races:
|
||||||
@@ -382,7 +382,7 @@ At this moment, the resolution for the two races:
|
|||||||
and ``setsockopt(TCP_AO_DEL_KEY)`` vs ``accept()`` is delegated to userspace.
|
and ``setsockopt(TCP_AO_DEL_KEY)`` vs ``accept()`` is delegated to userspace.
|
||||||
This means that it's expected that userspace would check the MKTs on the socket
|
This means that it's expected that userspace would check the MKTs on the socket
|
||||||
that was returned by ``accept()`` to verify that any key rotation that
|
that was returned by ``accept()`` to verify that any key rotation that
|
||||||
happened on listen socket is reflected on the newly established connection.
|
happened on the listen socket is reflected on the newly established connection.
|
||||||
|
|
||||||
This is a similar "do-nothing" approach to TCP-MD5 from the kernel side and
|
This is a similar "do-nothing" approach to TCP-MD5 from the kernel side and
|
||||||
may be changed later by introducing new flags to ``tcp_ao_add``
|
may be changed later by introducing new flags to ``tcp_ao_add``
|
||||||
|
|||||||
@@ -355,6 +355,8 @@ just do it. As a result, a sequence of smaller series gets merged quicker and
|
|||||||
with better review coverage. Re-posting large series also increases the mailing
|
with better review coverage. Re-posting large series also increases the mailing
|
||||||
list traffic.
|
list traffic.
|
||||||
|
|
||||||
|
.. _rcs:
|
||||||
|
|
||||||
Local variable ordering ("reverse xmas tree", "RCS")
|
Local variable ordering ("reverse xmas tree", "RCS")
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
@@ -391,6 +393,21 @@ APIs and helpers, especially scoped iterators. However, direct use of
|
|||||||
``__free()`` within networking core and drivers is discouraged.
|
``__free()`` within networking core and drivers is discouraged.
|
||||||
Similar guidance applies to declaring variables mid-function.
|
Similar guidance applies to declaring variables mid-function.
|
||||||
|
|
||||||
|
Clean-up patches
|
||||||
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Netdev discourages patches which perform simple clean-ups, which are not in
|
||||||
|
the context of other work. For example:
|
||||||
|
|
||||||
|
* Addressing ``checkpatch.pl`` warnings
|
||||||
|
* Addressing :ref:`Local variable ordering<rcs>` issues
|
||||||
|
* Conversions to device-managed APIs (``devm_`` helpers)
|
||||||
|
|
||||||
|
This is because it is felt that the churn that such changes produce comes
|
||||||
|
at a greater cost than the value of such clean-ups.
|
||||||
|
|
||||||
|
Conversely, spelling and grammar fixes are not discouraged.
|
||||||
|
|
||||||
Resending after review
|
Resending after review
|
||||||
~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
|||||||
@@ -30,10 +30,13 @@ tree as a dedicated branch covering multiple subsystems.
|
|||||||
The main SoC tree is housed on git.kernel.org:
|
The main SoC tree is housed on git.kernel.org:
|
||||||
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/
|
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/
|
||||||
|
|
||||||
|
Maintainers
|
||||||
|
-----------
|
||||||
|
|
||||||
Clearly this is quite a wide range of topics, which no one person, or even
|
Clearly this is quite a wide range of topics, which no one person, or even
|
||||||
small group of people are capable of maintaining. Instead, the SoC subsystem
|
small group of people are capable of maintaining. Instead, the SoC subsystem
|
||||||
is comprised of many submaintainers, each taking care of individual platforms
|
is comprised of many submaintainers (platform maintainers), each taking care of
|
||||||
and driver subdirectories.
|
individual platforms and driver subdirectories.
|
||||||
In this regard, "platform" usually refers to a series of SoCs from a given
|
In this regard, "platform" usually refers to a series of SoCs from a given
|
||||||
vendor, for example, Nvidia's series of Tegra SoCs. Many submaintainers operate
|
vendor, for example, Nvidia's series of Tegra SoCs. Many submaintainers operate
|
||||||
on a vendor level, responsible for multiple product lines. For several reasons,
|
on a vendor level, responsible for multiple product lines. For several reasons,
|
||||||
@@ -43,14 +46,43 @@ MAINTAINERS file.
|
|||||||
|
|
||||||
Most of these submaintainers have their own trees where they stage patches,
|
Most of these submaintainers have their own trees where they stage patches,
|
||||||
sending pull requests to the main SoC tree. These trees are usually, but not
|
sending pull requests to the main SoC tree. These trees are usually, but not
|
||||||
always, listed in MAINTAINERS. The main SoC maintainers can be reached via the
|
always, listed in MAINTAINERS.
|
||||||
alias soc@kernel.org if there is no platform-specific maintainer, or if they
|
|
||||||
are unresponsive.
|
|
||||||
|
|
||||||
What the SoC tree is not, however, is a location for architecture-specific code
|
What the SoC tree is not, however, is a location for architecture-specific code
|
||||||
changes. Each architecture has its own maintainers that are responsible for
|
changes. Each architecture has its own maintainers that are responsible for
|
||||||
architectural details, CPU errata and the like.
|
architectural details, CPU errata and the like.
|
||||||
|
|
||||||
|
Submitting Patches for Given SoC
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
All typical platform related patches should be sent via SoC submaintainers
|
||||||
|
(platform-specific maintainers). This includes also changes to per-platform or
|
||||||
|
shared defconfigs (scripts/get_maintainer.pl might not provide correct
|
||||||
|
addresses in such case).
|
||||||
|
|
||||||
|
Submitting Patches to the Main SoC Maintainers
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The main SoC maintainers can be reached via the alias soc@kernel.org only in
|
||||||
|
following cases:
|
||||||
|
|
||||||
|
1. There are no platform-specific maintainers.
|
||||||
|
|
||||||
|
2. Platform-specific maintainers are unresponsive.
|
||||||
|
|
||||||
|
3. Introducing a completely new SoC platform. Such new SoC work should be sent
|
||||||
|
first to common mailing lists, pointed out by scripts/get_maintainer.pl, for
|
||||||
|
community review. After positive community review, work should be sent to
|
||||||
|
soc@kernel.org in one patchset containing new arch/foo/Kconfig entry, DTS
|
||||||
|
files, MAINTAINERS file entry and optionally initial drivers with their
|
||||||
|
Devicetree bindings. The MAINTAINERS file entry should list new
|
||||||
|
platform-specific maintainers, who are going to be responsible for handling
|
||||||
|
patches for the platform from now on.
|
||||||
|
|
||||||
|
Note that the soc@kernel.org is usually not the place to discuss the patches,
|
||||||
|
thus work sent to this address should be already considered as acceptable by
|
||||||
|
the community.
|
||||||
|
|
||||||
Information for (new) Submaintainers
|
Information for (new) Submaintainers
|
||||||
------------------------------------
|
------------------------------------
|
||||||
|
|
||||||
|
|||||||
@@ -17,7 +17,7 @@ Architecture Level of support Constraints
|
|||||||
============= ================ ==============================================
|
============= ================ ==============================================
|
||||||
``arm64`` Maintained Little Endian only.
|
``arm64`` Maintained Little Endian only.
|
||||||
``loongarch`` Maintained \-
|
``loongarch`` Maintained \-
|
||||||
``riscv`` Maintained ``riscv64`` only.
|
``riscv`` Maintained ``riscv64`` and LLVM/Clang only.
|
||||||
``um`` Maintained \-
|
``um`` Maintained \-
|
||||||
``x86`` Maintained ``x86_64`` only.
|
``x86`` Maintained ``x86_64`` only.
|
||||||
============= ================ ==============================================
|
============= ================ ==============================================
|
||||||
|
|||||||
@@ -66,7 +66,7 @@ BPF scheduler and reverts all tasks back to CFS.
|
|||||||
.. code-block:: none
|
.. code-block:: none
|
||||||
|
|
||||||
# make -j16 -C tools/sched_ext
|
# make -j16 -C tools/sched_ext
|
||||||
# tools/sched_ext/scx_simple
|
# tools/sched_ext/build/bin/scx_simple
|
||||||
local=0 global=3
|
local=0 global=3
|
||||||
local=5 global=24
|
local=5 global=24
|
||||||
local=9 global=44
|
local=9 global=44
|
||||||
|
|||||||
@@ -175,7 +175,7 @@ field2会导致非对齐访问，这并不是不合理的。你会期望field2
|
|||||||
避免非对齐访问
|
避免非对齐访问
|
||||||
==============
|
==============
|
||||||
|
|
||||||
避免非对齐访问的最简单方法是使用<asm/unaligned.h>头文件提供的get_unaligned()和
|
避免非对齐访问的最简单方法是使用<linux/unaligned.h>头文件提供的get_unaligned()和
|
||||||
put_unaligned()宏。
|
put_unaligned()宏。
|
||||||
|
|
||||||
回到前面的一个可能导致非对齐访问的代码例子::
|
回到前面的一个可能导致非对齐访问的代码例子::
|
||||||
|
|||||||
@@ -23,177 +23,166 @@ applications can additionally seal security critical data at runtime.
|
|||||||
A similar feature already exists in the XNU kernel with the
|
A similar feature already exists in the XNU kernel with the
|
||||||
VM_FLAGS_PERMANENT flag [1] and on OpenBSD with the mimmutable syscall [2].
|
VM_FLAGS_PERMANENT flag [1] and on OpenBSD with the mimmutable syscall [2].
|
||||||
|
|
||||||
User API
|
SYSCALL
|
||||||
========
|
=======
|
||||||
mseal()
|
mseal syscall signature
|
||||||
-----------
|
-----------------------
|
||||||
The mseal() syscall has the following signature:
|
``int mseal(void \* addr, size_t len, unsigned long flags)``
|
||||||
|
|
||||||
``int mseal(void addr, size_t len, unsigned long flags)``
|
**addr**/**len**: virtual memory address range.
|
||||||
|
The address range set by **addr**/**len** must meet:
|
||||||
**addr/len**: virtual memory address range.
|
|
||||||
|
|
||||||
The address range set by ``addr``/``len`` must meet:
|
|
||||||
- The start address must be in an allocated VMA.
|
- The start address must be in an allocated VMA.
|
||||||
- The start address must be page aligned.
|
- The start address must be page aligned.
|
||||||
- The end address (``addr`` + ``len``) must be in an allocated VMA.
|
- The end address (**addr** + **len**) must be in an allocated VMA.
|
||||||
- no gap (unallocated memory) between start and end address.
|
- no gap (unallocated memory) between start and end address.
|
||||||
|
|
||||||
The ``len`` will be paged aligned implicitly by the kernel.
|
The ``len`` will be paged aligned implicitly by the kernel.
|
||||||
|
|
||||||
**flags**: reserved for future use.
|
**flags**: reserved for future use.
|
||||||
|
|
||||||
**return values**:
|
**Return values**:
|
||||||
|
- **0**: Success.
|
||||||
- ``0``: Success.
|
- **-EINVAL**:
|
||||||
|
* Invalid input ``flags``.
|
||||||
- ``-EINVAL``:
|
* The start address (``addr``) is not page aligned.
|
||||||
- Invalid input ``flags``.
|
* Address range (``addr`` + ``len``) overflow.
|
||||||
- The start address (``addr``) is not page aligned.
|
- **-ENOMEM**:
|
||||||
- Address range (``addr`` + ``len``) overflow.
|
* The start address (``addr``) is not allocated.
|
||||||
|
* The end address (``addr`` + ``len``) is not allocated.
|
||||||
- ``-ENOMEM``:
|
* A gap (unallocated memory) between start and end address.
|
||||||
- The start address (``addr``) is not allocated.
|
- **-EPERM**:
|
||||||
- The end address (``addr`` + ``len``) is not allocated.
|
* sealing is supported only on 64-bit CPUs, 32-bit is not supported.
|
||||||
- A gap (unallocated memory) between start and end address.
|
|
||||||
|
|
||||||
- ``-EPERM``:
|
|
||||||
- sealing is supported only on 64-bit CPUs, 32-bit is not supported.
|
|
||||||
|
|
||||||
|
**Note about error return**:
|
||||||
- For above error cases, users can expect the given memory range is
|
- For above error cases, users can expect the given memory range is
|
||||||
unmodified, i.e. no partial update.
|
unmodified, i.e. no partial update.
|
||||||
|
|
||||||
- There might be other internal errors/cases not listed here, e.g.
|
- There might be other internal errors/cases not listed here, e.g.
|
||||||
error during merging/splitting VMAs, or the process reaching the max
|
error during merging/splitting VMAs, or the process reaching the maximum
|
||||||
number of supported VMAs. In those cases, partial updates to the given
|
number of supported VMAs. In those cases, partial updates to the given
|
||||||
memory range could happen. However, those cases should be rare.
|
memory range could happen. However, those cases should be rare.
|
||||||
|
|
||||||
**Blocked operations after sealing**:
|
**Architecture support**:
|
||||||
Unmapping, moving to another location, and shrinking the size,
|
mseal only works on 64-bit CPUs, not 32-bit CPUs.
|
||||||
via munmap() and mremap(), can leave an empty space, therefore
|
|
||||||
can be replaced with a VMA with a new set of attributes.
|
|
||||||
|
|
||||||
Moving or expanding a different VMA into the current location,
|
**Idempotent**:
|
||||||
via mremap().
|
users can call mseal multiple times. mseal on an already sealed memory
|
||||||
|
|
||||||
Modifying a VMA via mmap(MAP_FIXED).
|
|
||||||
|
|
||||||
Size expansion, via mremap(), does not appear to pose any
|
|
||||||
specific risks to sealed VMAs. It is included anyway because
|
|
||||||
the use case is unclear. In any case, users can rely on
|
|
||||||
merging to expand a sealed VMA.
|
|
||||||
|
|
||||||
mprotect() and pkey_mprotect().
|
|
||||||
|
|
||||||
Some destructive madvice() behaviors (e.g. MADV_DONTNEED)
|
|
||||||
for anonymous memory, when users don't have write permission to the
|
|
||||||
memory. Those behaviors can alter region contents by discarding pages,
|
|
||||||
effectively a memset(0) for anonymous memory.
|
|
||||||
|
|
||||||
Kernel will return -EPERM for blocked operations.
|
|
||||||
|
|
||||||
For blocked operations, one can expect the given address is unmodified,
|
|
||||||
i.e. no partial update. Note, this is different from existing mm
|
|
||||||
system call behaviors, where partial updates are made till an error is
|
|
||||||
found and returned to userspace. To give an example:
|
|
||||||
|
|
||||||
Assume following code sequence:
|
|
||||||
|
|
||||||
- ptr = mmap(null, 8192, PROT_NONE);
|
|
||||||
- munmap(ptr + 4096, 4096);
|
|
||||||
- ret1 = mprotect(ptr, 8192, PROT_READ);
|
|
||||||
- mseal(ptr, 4096);
|
|
||||||
- ret2 = mprotect(ptr, 8192, PROT_NONE);
|
|
||||||
|
|
||||||
ret1 will be -ENOMEM, the page from ptr is updated to PROT_READ.
|
|
||||||
|
|
||||||
ret2 will be -EPERM, the page remains to be PROT_READ.
|
|
||||||
|
|
||||||
**Note**:
|
|
||||||
|
|
||||||
- mseal() only works on 64-bit CPUs, not 32-bit CPU.
|
|
||||||
|
|
||||||
- users can call mseal() multiple times, mseal() on an already sealed memory
|
|
||||||
is a no-action (not error).
|
is a no-action (not error).
|
||||||
|
|
||||||
- munseal() is not supported.
|
**no munseal**
|
||||||
|
Once mapping is sealed, it can't be unsealed. The kernel should never
|
||||||
|
have munseal, this is consistent with other sealing feature, e.g.
|
||||||
|
F_SEAL_SEAL for file.
|
||||||
|
|
||||||
Use cases:
|
Blocked mm syscall for sealed mapping
|
||||||
==========
|
-------------------------------------
|
||||||
|
It might be important to note: **once the mapping is sealed, it will
|
||||||
|
stay in the process's memory until the process terminates**.
|
||||||
|
|
||||||
|
Example::
|
||||||
|
|
||||||
|
*ptr = mmap(0, 4096, PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
|
||||||
|
rc = mseal(ptr, 4096, 0);
|
||||||
|
/* munmap will fail */
|
||||||
|
rc = munmap(ptr, 4096);
|
||||||
|
assert(rc < 0);
|
||||||
|
|
||||||
|
Blocked mm syscall:
|
||||||
|
- munmap
|
||||||
|
- mmap
|
||||||
|
- mremap
|
||||||
|
- mprotect and pkey_mprotect
|
||||||
|
- some destructive madvise behaviors: MADV_DONTNEED, MADV_FREE,
|
||||||
|
MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, MADV_WIPEONFORK
|
||||||
|
|
||||||
|
The first set of syscalls to block is munmap, mremap, mmap. They can
|
||||||
|
either leave an empty space in the address space, therefore allowing
|
||||||
|
replacement with a new mapping with new set of attributes, or can
|
||||||
|
overwrite the existing mapping with another mapping.
|
||||||
|
|
||||||
|
mprotect and pkey_mprotect are blocked because they changes the
|
||||||
|
protection bits (RWX) of the mapping.
|
||||||
|
|
||||||
|
Certain destructive madvise behaviors, specifically MADV_DONTNEED,
|
||||||
|
MADV_FREE, MADV_DONTNEED_LOCKED, and MADV_WIPEONFORK, can introduce
|
||||||
|
risks when applied to anonymous memory by threads lacking write
|
||||||
|
permissions. Consequently, these operations are prohibited under such
|
||||||
|
conditions. The aforementioned behaviors have the potential to modify
|
||||||
|
region contents by discarding pages, effectively performing a memset(0)
|
||||||
|
operation on the anonymous memory.
|
||||||
|
|
||||||
|
Kernel will return -EPERM for blocked syscalls.
|
||||||
|
|
||||||
|
When blocked syscall return -EPERM due to sealing, the memory regions may
|
||||||
|
or may not be changed, depends on the syscall being blocked:
|
||||||
|
|
||||||
|
- munmap: munmap is atomic. If one of VMAs in the given range is
|
||||||
|
sealed, none of VMAs are updated.
|
||||||
|
- mprotect, pkey_mprotect, madvise: partial update might happen, e.g.
|
||||||
|
when mprotect over multiple VMAs, mprotect might update the beginning
|
||||||
|
VMAs before reaching the sealed VMA and return -EPERM.
|
||||||
|
- mmap and mremap: undefined behavior.
|
||||||
|
|
||||||
|
Use cases
|
||||||
|
=========
|
||||||
- glibc:
|
- glibc:
|
||||||
The dynamic linker, during loading ELF executables, can apply sealing to
|
The dynamic linker, during loading ELF executables, can apply sealing to
|
||||||
non-writable memory segments.
|
mapping segments.
|
||||||
|
|
||||||
- Chrome browser: protect some security sensitive data-structures.
|
- Chrome browser: protect some security sensitive data structures.
|
||||||
|
|
||||||
Notes on which memory to seal:
|
When not to use mseal
|
||||||
==============================
|
=====================
|
||||||
|
Applications can apply sealing to any virtual memory region from userspace,
|
||||||
It might be important to note that sealing changes the lifetime of a mapping,
|
but it is *crucial to thoroughly analyze the mapping's lifetime* prior to
|
||||||
i.e. the sealed mapping won’t be unmapped till the process terminates or the
|
apply the sealing. This is because the sealed mapping *won’t be unmapped*
|
||||||
exec system call is invoked. Applications can apply sealing to any virtual
|
until the process terminates or the exec system call is invoked.
|
||||||
memory region from userspace, but it is crucial to thoroughly analyze the
|
|
||||||
mapping's lifetime prior to apply the sealing.
|
|
||||||
|
|
||||||
For example:
|
For example:
|
||||||
|
|
||||||
- aio/shm
|
- aio/shm
|
||||||
|
aio/shm can call mmap and munmap on behalf of userspace, e.g.
|
||||||
|
ksys_shmdt() in shm.c. The lifetimes of those mapping are not tied to
|
||||||
|
the lifetime of the process. If those memories are sealed from userspace,
|
||||||
|
then munmap will fail, causing leaks in VMA address space during the
|
||||||
|
lifetime of the process.
|
||||||
|
|
||||||
aio/shm can call mmap()/munmap() on behalf of userspace, e.g. ksys_shmdt() in
|
- ptr allocated by malloc (heap)
|
||||||
shm.c. The lifetime of those mapping are not tied to the lifetime of the
|
Don't use mseal on the memory ptr return from malloc().
|
||||||
process. If those memories are sealed from userspace, then munmap() will fail,
|
malloc() is implemented by allocator, e.g. by glibc. Heap manager might
|
||||||
causing leaks in VMA address space during the lifetime of the process.
|
allocate a ptr from brk or mapping created by mmap.
|
||||||
|
If an app calls mseal on a ptr returned from malloc(), this can affect
|
||||||
|
the heap manager's ability to manage the mappings; the outcome is
|
||||||
|
non-deterministic.
|
||||||
|
|
||||||
- Brk (heap)
|
Example::
|
||||||
|
|
||||||
Currently, userspace applications can seal parts of the heap by calling
|
ptr = malloc(size);
|
||||||
malloc() and mseal().
|
/* don't call mseal on ptr return from malloc. */
|
||||||
let's assume following calls from user space:
|
mseal(ptr, size);
|
||||||
|
/* free will success, allocator can't shrink heap lower than ptr */
|
||||||
|
free(ptr);
|
||||||
|
|
||||||
- ptr = malloc(size);
|
mseal doesn't block
|
||||||
- mprotect(ptr, size, RO);
|
===================
|
||||||
- mseal(ptr, size);
|
In a nutshell, mseal blocks certain mm syscall from modifying some of VMA's
|
||||||
- free(ptr);
|
attributes, such as protection bits (RWX). Sealed mappings doesn't mean the
|
||||||
|
memory is immutable.
|
||||||
|
|
||||||
Technically, before mseal() is added, the user can change the protection of
|
|
||||||
the heap by calling mprotect(RO). As long as the user changes the protection
|
|
||||||
back to RW before free(), the memory range can be reused.
|
|
||||||
|
|
||||||
Adding mseal() into the picture, however, the heap is then sealed partially,
|
|
||||||
the user can still free it, but the memory remains to be RO. If the address
|
|
||||||
is re-used by the heap manager for another malloc, the process might crash
|
|
||||||
soon after. Therefore, it is important not to apply sealing to any memory
|
|
||||||
that might get recycled.
|
|
||||||
|
|
||||||
Furthermore, even if the application never calls the free() for the ptr,
|
|
||||||
the heap manager may invoke the brk system call to shrink the size of the
|
|
||||||
heap. In the kernel, the brk-shrink will call munmap(). Consequently,
|
|
||||||
depending on the location of the ptr, the outcome of brk-shrink is
|
|
||||||
nondeterministic.
|
|
||||||
|
|
||||||
|
|
||||||
Additional notes:
|
|
||||||
=================
|
|
||||||
As Jann Horn pointed out in [3], there are still a few ways to write
|
As Jann Horn pointed out in [3], there are still a few ways to write
|
||||||
to RO memory, which is, in a way, by design. Those cases are not covered
|
to RO memory, which is, in a way, by design. And those could be blocked
|
||||||
by mseal(). If applications want to block such cases, sandbox tools (such as
|
by different security measures.
|
||||||
seccomp, LSM, etc) might be considered.
|
|
||||||
|
|
||||||
Those cases are:
|
Those cases are:
|
||||||
|
|
||||||
- Write to read-only memory through /proc/self/mem interface.
|
- Write to read-only memory through /proc/self/mem interface (FOLL_FORCE).
|
||||||
- Write to read-only memory through ptrace (such as PTRACE_POKETEXT).
|
- Write to read-only memory through ptrace (such as PTRACE_POKETEXT).
|
||||||
- userfaultfd.
|
- userfaultfd.
|
||||||
|
|
||||||
The idea that inspired this patch comes from Stephen Röttger’s work in V8
|
The idea that inspired this patch comes from Stephen Röttger’s work in V8
|
||||||
CFI [4]. Chrome browser in ChromeOS will be the first user of this API.
|
CFI [4]. Chrome browser in ChromeOS will be the first user of this API.
|
||||||
|
|
||||||
Reference:
|
Reference
|
||||||
==========
|
=========
|
||||||
[1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274
|
- [1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274
|
||||||
|
- [2] https://man.openbsd.org/mimmutable.2
|
||||||
[2] https://man.openbsd.org/mimmutable.2
|
- [3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com
|
||||||
|
- [4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc
|
||||||
[3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com
|
|
||||||
|
|
||||||
[4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc
|
|
||||||
|
|||||||
@@ -8098,13 +8098,15 @@ KVM_X86_QUIRK_MWAIT_NEVER_UD_FAULTS By default, KVM emulates MONITOR/MWAIT (if
|
|||||||
KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT is
|
KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT is
|
||||||
disabled.
|
disabled.
|
||||||
|
|
||||||
KVM_X86_QUIRK_SLOT_ZAP_ALL By default, KVM invalidates all SPTEs in
|
KVM_X86_QUIRK_SLOT_ZAP_ALL By default, for KVM_X86_DEFAULT_VM VMs, KVM
|
||||||
fast way for memslot deletion when VM type
|
invalidates all SPTEs in all memslots and
|
||||||
is KVM_X86_DEFAULT_VM.
|
address spaces when a memslot is deleted or
|
||||||
When this quirk is disabled or when VM type
|
moved. When this quirk is disabled (or the
|
||||||
is other than KVM_X86_DEFAULT_VM, KVM zaps
|
VM type isn't KVM_X86_DEFAULT_VM), KVM only
|
||||||
only leaf SPTEs that are within the range of
|
ensures the backing memory of the deleted
|
||||||
the memslot being deleted.
|
or moved memslot isn't reachable, i.e KVM
|
||||||
|
_may_ invalidate only SPTEs related to the
|
||||||
|
memslot.
|
||||||
=================================== ============================================
|
=================================== ============================================
|
||||||
|
|
||||||
7.32 KVM_CAP_MAX_VCPU_ID
|
7.32 KVM_CAP_MAX_VCPU_ID
|
||||||
|
|||||||
@@ -136,7 +136,7 @@ For direct sp, we can easily avoid it since the spte of direct sp is fixed
|
|||||||
to gfn. For indirect sp, we disabled fast page fault for simplicity.
|
to gfn. For indirect sp, we disabled fast page fault for simplicity.
|
||||||
|
|
||||||
A solution for indirect sp could be to pin the gfn, for example via
|
A solution for indirect sp could be to pin the gfn, for example via
|
||||||
kvm_vcpu_gfn_to_pfn_atomic, before the cmpxchg. After the pinning:
|
gfn_to_pfn_memslot_atomic, before the cmpxchg. After the pinning:
|
||||||
|
|
||||||
- We have held the refcount of pfn; that means the pfn can not be freed and
|
- We have held the refcount of pfn; that means the pfn can not be freed and
|
||||||
be reused for another gfn.
|
be reused for another gfn.
|
||||||
|
|||||||
@@ -8,7 +8,7 @@ Introduction
|
|||||||
============
|
============
|
||||||
|
|
||||||
Many Dell notebooks made after ~2020 support a WMI-based interface for
|
Many Dell notebooks made after ~2020 support a WMI-based interface for
|
||||||
retrieving various system data like battery temperature, ePPID, diagostic data
|
retrieving various system data like battery temperature, ePPID, diagnostic data
|
||||||
and fan/thermal sensor data.
|
and fan/thermal sensor data.
|
||||||
|
|
||||||
This interface is likely used by the `Dell Data Vault` software on Windows,
|
This interface is likely used by the `Dell Data Vault` software on Windows,
|
||||||
@@ -277,7 +277,7 @@ Reverse-Engineering the DDV WMI interface
|
|||||||
4. Try to deduce the meaning of a certain WMI method by comparing the control
|
4. Try to deduce the meaning of a certain WMI method by comparing the control
|
||||||
flow with other ACPI methods (_BIX or _BIF for battery related methods
|
flow with other ACPI methods (_BIX or _BIF for battery related methods
|
||||||
for example).
|
for example).
|
||||||
5. Use the built-in UEFI diagostics to view sensor types/values for fan/thermal
|
5. Use the built-in UEFI diagnostics to view sensor types/values for fan/thermal
|
||||||
related methods (sometimes overwriting static ACPI data fields can be used
|
related methods (sometimes overwriting static ACPI data fields can be used
|
||||||
to test different sensor type values, since on some machines this data is
|
to test different sensor type values, since on some machines this data is
|
||||||
not reinitialized upon a warm reset).
|
not reinitialized upon a warm reset).
|
||||||
|
|||||||
323
MAINTAINERS
323
MAINTAINERS
@@ -258,12 +258,6 @@ L: linux-acenic@sunsite.dk
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/net/ethernet/alteon/acenic*
|
F: drivers/net/ethernet/alteon/acenic*
|
||||||
|
|
||||||
ACER ASPIRE 1 EMBEDDED CONTROLLER DRIVER
|
|
||||||
M: Nikita Travkin <nikita@trvn.ru>
|
|
||||||
S: Maintained
|
|
||||||
F: Documentation/devicetree/bindings/platform/acer,aspire1-ec.yaml
|
|
||||||
F: drivers/platform/arm64/acer-aspire1-ec.c
|
|
||||||
|
|
||||||
ACER ASPIRE ONE TEMPERATURE AND FAN DRIVER
|
ACER ASPIRE ONE TEMPERATURE AND FAN DRIVER
|
||||||
M: Peter Kaestle <peter@piie.net>
|
M: Peter Kaestle <peter@piie.net>
|
||||||
L: platform-driver-x86@vger.kernel.org
|
L: platform-driver-x86@vger.kernel.org
|
||||||
@@ -860,7 +854,7 @@ F: drivers/crypto/allwinner/
|
|||||||
|
|
||||||
ALLWINNER DMIC DRIVERS
|
ALLWINNER DMIC DRIVERS
|
||||||
M: Ban Tao <fengzheng923@gmail.com>
|
M: Ban Tao <fengzheng923@gmail.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/allwinner,sun50i-h6-dmic.yaml
|
F: Documentation/devicetree/bindings/sound/allwinner,sun50i-h6-dmic.yaml
|
||||||
F: sound/soc/sunxi/sun50i-dmic.c
|
F: sound/soc/sunxi/sun50i-dmic.c
|
||||||
@@ -888,7 +882,6 @@ F: drivers/staging/media/sunxi/cedrus/
|
|||||||
|
|
||||||
ALPHA PORT
|
ALPHA PORT
|
||||||
M: Richard Henderson <richard.henderson@linaro.org>
|
M: Richard Henderson <richard.henderson@linaro.org>
|
||||||
M: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
|
|
||||||
M: Matt Turner <mattst88@gmail.com>
|
M: Matt Turner <mattst88@gmail.com>
|
||||||
L: linux-alpha@vger.kernel.org
|
L: linux-alpha@vger.kernel.org
|
||||||
S: Odd Fixes
|
S: Odd Fixes
|
||||||
@@ -1517,7 +1510,7 @@ F: drivers/iio/gyro/adxrs290.c
|
|||||||
ANALOG DEVICES INC ASOC CODEC DRIVERS
|
ANALOG DEVICES INC ASOC CODEC DRIVERS
|
||||||
M: Lars-Peter Clausen <lars@metafoo.de>
|
M: Lars-Peter Clausen <lars@metafoo.de>
|
||||||
M: Nuno Sá <nuno.sa@analog.com>
|
M: Nuno Sá <nuno.sa@analog.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
W: http://wiki.analog.com/
|
W: http://wiki.analog.com/
|
||||||
W: https://ez.analog.com/linux-software-drivers
|
W: https://ez.analog.com/linux-software-drivers
|
||||||
@@ -1594,7 +1587,7 @@ F: drivers/rtc/rtc-goldfish.c
|
|||||||
AOA (Apple Onboard Audio) ALSA DRIVER
|
AOA (Apple Onboard Audio) ALSA DRIVER
|
||||||
M: Johannes Berg <johannes@sipsolutions.net>
|
M: Johannes Berg <johannes@sipsolutions.net>
|
||||||
L: linuxppc-dev@lists.ozlabs.org
|
L: linuxppc-dev@lists.ozlabs.org
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: sound/aoa/
|
F: sound/aoa/
|
||||||
|
|
||||||
@@ -1761,8 +1754,8 @@ F: include/uapi/linux/if_arcnet.h
|
|||||||
ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
|
ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
|
||||||
M: Arnd Bergmann <arnd@arndb.de>
|
M: Arnd Bergmann <arnd@arndb.de>
|
||||||
M: Olof Johansson <olof@lixom.net>
|
M: Olof Johansson <olof@lixom.net>
|
||||||
M: soc@kernel.org
|
|
||||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||||
|
L: soc@lists.linux.dev
|
||||||
S: Maintained
|
S: Maintained
|
||||||
P: Documentation/process/maintainer-soc.rst
|
P: Documentation/process/maintainer-soc.rst
|
||||||
C: irc://irc.libera.chat/armlinux
|
C: irc://irc.libera.chat/armlinux
|
||||||
@@ -2091,7 +2084,7 @@ F: drivers/crypto/amlogic/
|
|||||||
|
|
||||||
ARM/Amlogic Meson SoC Sound Drivers
|
ARM/Amlogic Meson SoC Sound Drivers
|
||||||
M: Jerome Brunet <jbrunet@baylibre.com>
|
M: Jerome Brunet <jbrunet@baylibre.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/amlogic*
|
F: Documentation/devicetree/bindings/sound/amlogic*
|
||||||
F: sound/soc/meson/
|
F: sound/soc/meson/
|
||||||
@@ -2129,7 +2122,7 @@ F: drivers/*/*alpine*
|
|||||||
ARM/APPLE MACHINE SOUND DRIVERS
|
ARM/APPLE MACHINE SOUND DRIVERS
|
||||||
M: Martin Povišer <povik+lin@cutebit.org>
|
M: Martin Povišer <povik+lin@cutebit.org>
|
||||||
L: asahi@lists.linux.dev
|
L: asahi@lists.linux.dev
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/adi,ssm3515.yaml
|
F: Documentation/devicetree/bindings/sound/adi,ssm3515.yaml
|
||||||
F: Documentation/devicetree/bindings/sound/apple,*
|
F: Documentation/devicetree/bindings/sound/apple,*
|
||||||
@@ -2263,12 +2256,6 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: arch/arm/mach-ep93xx/ts72xx.c
|
F: arch/arm/mach-ep93xx/ts72xx.c
|
||||||
|
|
||||||
ARM/CIRRUS LOGIC CLPS711X ARM ARCHITECTURE
|
|
||||||
M: Alexander Shiyan <shc_work@mail.ru>
|
|
||||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
|
||||||
S: Odd Fixes
|
|
||||||
N: clps711x
|
|
||||||
|
|
||||||
ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE
|
ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE
|
||||||
M: Hartley Sweeten <hsweeten@visionengravers.com>
|
M: Hartley Sweeten <hsweeten@visionengravers.com>
|
||||||
M: Alexander Sverdlin <alexander.sverdlin@gmail.com>
|
M: Alexander Sverdlin <alexander.sverdlin@gmail.com>
|
||||||
@@ -3732,7 +3719,7 @@ F: arch/arm/boot/dts/microchip/at91-tse850-3.dts
|
|||||||
|
|
||||||
AXENTIA ASOC DRIVERS
|
AXENTIA ASOC DRIVERS
|
||||||
M: Peter Rosin <peda@axentia.se>
|
M: Peter Rosin <peda@axentia.se>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/axentia,*
|
F: Documentation/devicetree/bindings/sound/axentia,*
|
||||||
F: sound/soc/atmel/tse850-pcm5142.c
|
F: sound/soc/atmel/tse850-pcm5142.c
|
||||||
@@ -3815,14 +3802,6 @@ F: drivers/video/backlight/
|
|||||||
F: include/linux/backlight.h
|
F: include/linux/backlight.h
|
||||||
F: include/linux/pwm_backlight.h
|
F: include/linux/pwm_backlight.h
|
||||||
|
|
||||||
BAIKAL-T1 PVT HARDWARE MONITOR DRIVER
|
|
||||||
M: Serge Semin <fancer.lancer@gmail.com>
|
|
||||||
L: linux-hwmon@vger.kernel.org
|
|
||||||
S: Supported
|
|
||||||
F: Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml
|
|
||||||
F: Documentation/hwmon/bt1-pvt.rst
|
|
||||||
F: drivers/hwmon/bt1-pvt.[ch]
|
|
||||||
|
|
||||||
BARCO P50 GPIO DRIVER
|
BARCO P50 GPIO DRIVER
|
||||||
M: Santosh Kumar Yadav <santoshkumar.yadav@barco.com>
|
M: Santosh Kumar Yadav <santoshkumar.yadav@barco.com>
|
||||||
M: Peter Korsgaard <peter.korsgaard@barco.com>
|
M: Peter Korsgaard <peter.korsgaard@barco.com>
|
||||||
@@ -4851,7 +4830,7 @@ F: include/uapi/linux/bsg.h
|
|||||||
|
|
||||||
BT87X AUDIO DRIVER
|
BT87X AUDIO DRIVER
|
||||||
M: Clemens Ladisch <clemens@ladisch.de>
|
M: Clemens Ladisch <clemens@ladisch.de>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||||
F: Documentation/sound/cards/bt87x.rst
|
F: Documentation/sound/cards/bt87x.rst
|
||||||
@@ -4913,7 +4892,7 @@ F: drivers/net/can/bxcan.c
|
|||||||
|
|
||||||
C-MEDIA CMI8788 DRIVER
|
C-MEDIA CMI8788 DRIVER
|
||||||
M: Clemens Ladisch <clemens@ladisch.de>
|
M: Clemens Ladisch <clemens@ladisch.de>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||||
F: sound/pci/oxygen/
|
F: sound/pci/oxygen/
|
||||||
@@ -6476,7 +6455,6 @@ F: drivers/mtd/nand/raw/denali*
|
|||||||
|
|
||||||
DESIGNWARE EDMA CORE IP DRIVER
|
DESIGNWARE EDMA CORE IP DRIVER
|
||||||
M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
||||||
R: Serge Semin <fancer.lancer@gmail.com>
|
|
||||||
L: dmaengine@vger.kernel.org
|
L: dmaengine@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/dma/dw-edma/
|
F: drivers/dma/dw-edma/
|
||||||
@@ -7097,12 +7075,10 @@ M: Javier Martinez Canillas <javierm@redhat.com>
|
|||||||
L: dri-devel@lists.freedesktop.org
|
L: dri-devel@lists.freedesktop.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||||
F: drivers/gpu/drm/drm_aperture.c
|
|
||||||
F: drivers/gpu/drm/tiny/ofdrm.c
|
F: drivers/gpu/drm/tiny/ofdrm.c
|
||||||
F: drivers/gpu/drm/tiny/simpledrm.c
|
F: drivers/gpu/drm/tiny/simpledrm.c
|
||||||
F: drivers/video/aperture.c
|
F: drivers/video/aperture.c
|
||||||
F: drivers/video/nomodeset.c
|
F: drivers/video/nomodeset.c
|
||||||
F: include/drm/drm_aperture.h
|
|
||||||
F: include/linux/aperture.h
|
F: include/linux/aperture.h
|
||||||
F: include/video/nomodeset.h
|
F: include/video/nomodeset.h
|
||||||
|
|
||||||
@@ -7383,6 +7359,18 @@ S: Maintained
|
|||||||
F: Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
|
F: Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
|
||||||
F: drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
|
F: drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
|
||||||
|
|
||||||
|
DRM DRIVER FOR SAMSUNG S6E3HA8 PANELS
|
||||||
|
M: Dzmitry Sankouski <dsankouski@gmail.com>
|
||||||
|
S: Maintained
|
||||||
|
F: Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml
|
||||||
|
F: drivers/gpu/drm/panel/panel-samsung-s6e3ha8.c
|
||||||
|
|
||||||
|
DRM DRIVER FOR SHARP MEMORY LCD
|
||||||
|
M: Alex Lanzano <lanzano.alex@gmail.com>
|
||||||
|
S: Maintained
|
||||||
|
F: Documentation/devicetree/bindings/display/sharp,ls010b7dh04.yaml
|
||||||
|
F: drivers/gpu/drm/tiny/sharp-memory.c
|
||||||
|
|
||||||
DRM DRIVER FOR SITRONIX ST7586 PANELS
|
DRM DRIVER FOR SITRONIX ST7586 PANELS
|
||||||
M: David Lechner <david@lechnology.com>
|
M: David Lechner <david@lechnology.com>
|
||||||
S: Maintained
|
S: Maintained
|
||||||
@@ -7460,8 +7448,8 @@ T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
|||||||
F: drivers/gpu/drm/udl/
|
F: drivers/gpu/drm/udl/
|
||||||
|
|
||||||
DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS)
|
DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS)
|
||||||
M: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
|
|
||||||
M: Maíra Canal <mairacanal@riseup.net>
|
M: Maíra Canal <mairacanal@riseup.net>
|
||||||
|
M: Louis Chauvet <louis.chauvet@bootlin.com>
|
||||||
R: Haneen Mohammed <hamohammed.sa@gmail.com>
|
R: Haneen Mohammed <hamohammed.sa@gmail.com>
|
||||||
R: Simona Vetter <simona@ffwll.ch>
|
R: Simona Vetter <simona@ffwll.ch>
|
||||||
R: Melissa Wen <melissa.srw@gmail.com>
|
R: Melissa Wen <melissa.srw@gmail.com>
|
||||||
@@ -7793,6 +7781,7 @@ F: include/uapi/drm/v3d_drm.h
|
|||||||
DRM DRIVERS FOR VC4
|
DRM DRIVERS FOR VC4
|
||||||
M: Maxime Ripard <mripard@kernel.org>
|
M: Maxime Ripard <mripard@kernel.org>
|
||||||
M: Dave Stevenson <dave.stevenson@raspberrypi.com>
|
M: Dave Stevenson <dave.stevenson@raspberrypi.com>
|
||||||
|
R: Maíra Canal <mcanal@igalia.com>
|
||||||
R: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
|
R: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
|
||||||
S: Supported
|
S: Supported
|
||||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||||
@@ -7827,11 +7816,14 @@ L: dri-devel@lists.freedesktop.org
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||||
F: Documentation/devicetree/bindings/display/xlnx/
|
F: Documentation/devicetree/bindings/display/xlnx/
|
||||||
|
F: Documentation/gpu/zynqmp.rst
|
||||||
F: drivers/gpu/drm/xlnx/
|
F: drivers/gpu/drm/xlnx/
|
||||||
|
|
||||||
DRM GPU SCHEDULER
|
DRM GPU SCHEDULER
|
||||||
M: Luben Tuikov <ltuikov89@gmail.com>
|
M: Luben Tuikov <ltuikov89@gmail.com>
|
||||||
M: Matthew Brost <matthew.brost@intel.com>
|
M: Matthew Brost <matthew.brost@intel.com>
|
||||||
|
M: Danilo Krummrich <dakr@kernel.org>
|
||||||
|
M: Philipp Stanner <pstanner@redhat.com>
|
||||||
L: dri-devel@lists.freedesktop.org
|
L: dri-devel@lists.freedesktop.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||||
@@ -8252,7 +8244,7 @@ F: drivers/edac/ti_edac.c
|
|||||||
|
|
||||||
EDIROL UA-101/UA-1000 DRIVER
|
EDIROL UA-101/UA-1000 DRIVER
|
||||||
M: Clemens Ladisch <clemens@ladisch.de>
|
M: Clemens Ladisch <clemens@ladisch.de>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||||
F: sound/usb/misc/ua101.c
|
F: sound/usb/misc/ua101.c
|
||||||
@@ -8814,7 +8806,7 @@ F: drivers/net/can/usb/f81604.c
|
|||||||
FIREWIRE AUDIO DRIVERS and IEC 61883-1/6 PACKET STREAMING ENGINE
|
FIREWIRE AUDIO DRIVERS and IEC 61883-1/6 PACKET STREAMING ENGINE
|
||||||
M: Clemens Ladisch <clemens@ladisch.de>
|
M: Clemens Ladisch <clemens@ladisch.de>
|
||||||
M: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
M: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||||
F: include/uapi/sound/firewire.h
|
F: include/uapi/sound/firewire.h
|
||||||
@@ -8888,7 +8880,7 @@ F: drivers/input/joystick/fsia6b.c
|
|||||||
|
|
||||||
FOCUSRITE SCARLETT2 MIXER DRIVER (Scarlett Gen 2+ and Clarett)
|
FOCUSRITE SCARLETT2 MIXER DRIVER (Scarlett Gen 2+ and Clarett)
|
||||||
M: Geoffrey D. Bennett <g@b4.vu>
|
M: Geoffrey D. Bennett <g@b4.vu>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
W: https://github.com/geoffreybennett/scarlett-gen2
|
W: https://github.com/geoffreybennett/scarlett-gen2
|
||||||
B: https://github.com/geoffreybennett/scarlett-gen2/issues
|
B: https://github.com/geoffreybennett/scarlett-gen2/issues
|
||||||
@@ -8912,6 +8904,7 @@ F: include/linux/fortify-string.h
|
|||||||
F: lib/fortify_kunit.c
|
F: lib/fortify_kunit.c
|
||||||
F: lib/memcpy_kunit.c
|
F: lib/memcpy_kunit.c
|
||||||
F: lib/test_fortify/*
|
F: lib/test_fortify/*
|
||||||
|
K: \bunsafe_memcpy\b
|
||||||
K: \b__NO_FORTIFY\b
|
K: \b__NO_FORTIFY\b
|
||||||
|
|
||||||
FPGA DFL DRIVERS
|
FPGA DFL DRIVERS
|
||||||
@@ -9209,7 +9202,7 @@ M: Shengjiu Wang <shengjiu.wang@gmail.com>
|
|||||||
M: Xiubo Li <Xiubo.Lee@gmail.com>
|
M: Xiubo Li <Xiubo.Lee@gmail.com>
|
||||||
R: Fabio Estevam <festevam@gmail.com>
|
R: Fabio Estevam <festevam@gmail.com>
|
||||||
R: Nicolin Chen <nicoleotsuka@gmail.com>
|
R: Nicolin Chen <nicoleotsuka@gmail.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
L: linuxppc-dev@lists.ozlabs.org
|
L: linuxppc-dev@lists.ozlabs.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: sound/soc/fsl/fsl*
|
F: sound/soc/fsl/fsl*
|
||||||
@@ -9219,7 +9212,7 @@ FREESCALE SOC LPC32XX SOUND DRIVERS
|
|||||||
M: J.M.B. Downing <jonathan.downing@nautel.com>
|
M: J.M.B. Downing <jonathan.downing@nautel.com>
|
||||||
M: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
|
M: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
|
||||||
R: Vladimir Zapolskiy <vz@mleia.com>
|
R: Vladimir Zapolskiy <vz@mleia.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
L: linuxppc-dev@lists.ozlabs.org
|
L: linuxppc-dev@lists.ozlabs.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/nxp,lpc3220-i2s.yaml
|
F: Documentation/devicetree/bindings/sound/nxp,lpc3220-i2s.yaml
|
||||||
@@ -9227,7 +9220,7 @@ F: sound/soc/fsl/lpc3xxx-*
|
|||||||
|
|
||||||
FREESCALE SOC SOUND QMC DRIVER
|
FREESCALE SOC SOUND QMC DRIVER
|
||||||
M: Herve Codina <herve.codina@bootlin.com>
|
M: Herve Codina <herve.codina@bootlin.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
L: linuxppc-dev@lists.ozlabs.org
|
L: linuxppc-dev@lists.ozlabs.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
|
F: Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
|
||||||
@@ -9742,6 +9735,7 @@ F: include/dt-bindings/gpio/
|
|||||||
F: include/linux/gpio.h
|
F: include/linux/gpio.h
|
||||||
F: include/linux/gpio/
|
F: include/linux/gpio/
|
||||||
F: include/linux/of_gpio.h
|
F: include/linux/of_gpio.h
|
||||||
|
K: (devm_)?gpio_(request|free|direction|get|set)
|
||||||
|
|
||||||
GPIO UAPI
|
GPIO UAPI
|
||||||
M: Bartosz Golaszewski <brgl@bgdev.pl>
|
M: Bartosz Golaszewski <brgl@bgdev.pl>
|
||||||
@@ -9756,14 +9750,6 @@ F: drivers/gpio/gpiolib-cdev.c
|
|||||||
F: include/uapi/linux/gpio.h
|
F: include/uapi/linux/gpio.h
|
||||||
F: tools/gpio/
|
F: tools/gpio/
|
||||||
|
|
||||||
GRE DEMULTIPLEXER DRIVER
|
|
||||||
M: Dmitry Kozlov <xeb@mail.ru>
|
|
||||||
L: netdev@vger.kernel.org
|
|
||||||
S: Maintained
|
|
||||||
F: include/net/gre.h
|
|
||||||
F: net/ipv4/gre_demux.c
|
|
||||||
F: net/ipv4/gre_offload.c
|
|
||||||
|
|
||||||
GRETH 10/100/1G Ethernet MAC device driver
|
GRETH 10/100/1G Ethernet MAC device driver
|
||||||
M: Andreas Larsson <andreas@gaisler.com>
|
M: Andreas Larsson <andreas@gaisler.com>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
@@ -10267,7 +10253,7 @@ F: Documentation/devicetree/bindings/arm/hisilicon/low-pin-count.yaml
|
|||||||
F: drivers/bus/hisi_lpc.c
|
F: drivers/bus/hisi_lpc.c
|
||||||
|
|
||||||
HISILICON NETWORK SUBSYSTEM 3 DRIVER (HNS3)
|
HISILICON NETWORK SUBSYSTEM 3 DRIVER (HNS3)
|
||||||
M: Yisen Zhuang <yisen.zhuang@huawei.com>
|
M: Jian Shen <shenjian15@huawei.com>
|
||||||
M: Salil Mehta <salil.mehta@huawei.com>
|
M: Salil Mehta <salil.mehta@huawei.com>
|
||||||
M: Jijie Shao <shaojijie@huawei.com>
|
M: Jijie Shao <shaojijie@huawei.com>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
@@ -10276,7 +10262,7 @@ W: http://www.hisilicon.com
|
|||||||
F: drivers/net/ethernet/hisilicon/hns3/
|
F: drivers/net/ethernet/hisilicon/hns3/
|
||||||
|
|
||||||
HISILICON NETWORK SUBSYSTEM DRIVER
|
HISILICON NETWORK SUBSYSTEM DRIVER
|
||||||
M: Yisen Zhuang <yisen.zhuang@huawei.com>
|
M: Jian Shen <shenjian15@huawei.com>
|
||||||
M: Salil Mehta <salil.mehta@huawei.com>
|
M: Salil Mehta <salil.mehta@huawei.com>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
@@ -11154,7 +11140,7 @@ F: drivers/iio/pressure/dps310.c
|
|||||||
|
|
||||||
INFINEON PEB2466 ASoC CODEC
|
INFINEON PEB2466 ASoC CODEC
|
||||||
M: Herve Codina <herve.codina@bootlin.com>
|
M: Herve Codina <herve.codina@bootlin.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/infineon,peb2466.yaml
|
F: Documentation/devicetree/bindings/sound/infineon,peb2466.yaml
|
||||||
F: sound/soc/codecs/peb2466.c
|
F: sound/soc/codecs/peb2466.c
|
||||||
@@ -11280,10 +11266,10 @@ F: security/integrity/
|
|||||||
F: security/integrity/ima/
|
F: security/integrity/ima/
|
||||||
|
|
||||||
INTEGRITY POLICY ENFORCEMENT (IPE)
|
INTEGRITY POLICY ENFORCEMENT (IPE)
|
||||||
M: Fan Wu <wufan@linux.microsoft.com>
|
M: Fan Wu <wufan@kernel.org>
|
||||||
L: linux-security-module@vger.kernel.org
|
L: linux-security-module@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
T: git https://github.com/microsoft/ipe.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe.git
|
||||||
F: Documentation/admin-guide/LSM/ipe.rst
|
F: Documentation/admin-guide/LSM/ipe.rst
|
||||||
F: Documentation/security/ipe.rst
|
F: Documentation/security/ipe.rst
|
||||||
F: scripts/ipe/
|
F: scripts/ipe/
|
||||||
@@ -11317,7 +11303,7 @@ M: Bard Liao <yung-chuan.liao@linux.intel.com>
|
|||||||
M: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
|
M: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
|
||||||
M: Kai Vehmanen <kai.vehmanen@linux.intel.com>
|
M: Kai Vehmanen <kai.vehmanen@linux.intel.com>
|
||||||
R: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
|
R: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: sound/soc/intel/
|
F: sound/soc/intel/
|
||||||
|
|
||||||
@@ -11496,7 +11482,7 @@ F: include/uapi/linux/idxd.h
|
|||||||
|
|
||||||
INTEL IN FIELD SCAN (IFS) DEVICE
|
INTEL IN FIELD SCAN (IFS) DEVICE
|
||||||
M: Jithu Joseph <jithu.joseph@intel.com>
|
M: Jithu Joseph <jithu.joseph@intel.com>
|
||||||
R: Ashok Raj <ashok.raj@intel.com>
|
R: Ashok Raj <ashok.raj.linux@gmail.com>
|
||||||
R: Tony Luck <tony.luck@intel.com>
|
R: Tony Luck <tony.luck@intel.com>
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/platform/x86/intel/ifs
|
F: drivers/platform/x86/intel/ifs
|
||||||
@@ -11601,6 +11587,16 @@ F: drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c
|
|||||||
F: drivers/crypto/intel/keembay/ocs-hcu.c
|
F: drivers/crypto/intel/keembay/ocs-hcu.c
|
||||||
F: drivers/crypto/intel/keembay/ocs-hcu.h
|
F: drivers/crypto/intel/keembay/ocs-hcu.h
|
||||||
|
|
||||||
|
INTEL LA JOLLA COVE ADAPTER (LJCA) USB I/O EXPANDER DRIVERS
|
||||||
|
M: Wentong Wu <wentong.wu@intel.com>
|
||||||
|
M: Sakari Ailus <sakari.ailus@linux.intel.com>
|
||||||
|
S: Maintained
|
||||||
|
F: drivers/gpio/gpio-ljca.c
|
||||||
|
F: drivers/i2c/busses/i2c-ljca.c
|
||||||
|
F: drivers/spi/spi-ljca.c
|
||||||
|
F: drivers/usb/misc/usb-ljca.c
|
||||||
|
F: include/linux/usb/ljca.h
|
||||||
|
|
||||||
INTEL MANAGEMENT ENGINE (mei)
|
INTEL MANAGEMENT ENGINE (mei)
|
||||||
M: Tomas Winkler <tomas.winkler@intel.com>
|
M: Tomas Winkler <tomas.winkler@intel.com>
|
||||||
L: linux-kernel@vger.kernel.org
|
L: linux-kernel@vger.kernel.org
|
||||||
@@ -12001,7 +11997,7 @@ F: drivers/tty/ipwireless/
|
|||||||
|
|
||||||
IRON DEVICE AUDIO CODEC DRIVERS
|
IRON DEVICE AUDIO CODEC DRIVERS
|
||||||
M: Kiseok Jo <kiseok.jo@irondevice.com>
|
M: Kiseok Jo <kiseok.jo@irondevice.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/irondevice,*
|
F: Documentation/devicetree/bindings/sound/irondevice,*
|
||||||
F: sound/soc/codecs/sma*
|
F: sound/soc/codecs/sma*
|
||||||
@@ -12239,6 +12235,7 @@ R: Dmitry Vyukov <dvyukov@google.com>
|
|||||||
R: Vincenzo Frascino <vincenzo.frascino@arm.com>
|
R: Vincenzo Frascino <vincenzo.frascino@arm.com>
|
||||||
L: kasan-dev@googlegroups.com
|
L: kasan-dev@googlegroups.com
|
||||||
S: Maintained
|
S: Maintained
|
||||||
|
B: https://bugzilla.kernel.org/buglist.cgi?component=Sanitizers&product=Memory%20Management
|
||||||
F: Documentation/dev-tools/kasan.rst
|
F: Documentation/dev-tools/kasan.rst
|
||||||
F: arch/*/include/asm/*kasan.h
|
F: arch/*/include/asm/*kasan.h
|
||||||
F: arch/*/mm/kasan_init*
|
F: arch/*/mm/kasan_init*
|
||||||
@@ -12262,6 +12259,7 @@ R: Dmitry Vyukov <dvyukov@google.com>
|
|||||||
R: Andrey Konovalov <andreyknvl@gmail.com>
|
R: Andrey Konovalov <andreyknvl@gmail.com>
|
||||||
L: kasan-dev@googlegroups.com
|
L: kasan-dev@googlegroups.com
|
||||||
S: Maintained
|
S: Maintained
|
||||||
|
B: https://bugzilla.kernel.org/buglist.cgi?component=Sanitizers&product=Memory%20Management
|
||||||
F: Documentation/dev-tools/kcov.rst
|
F: Documentation/dev-tools/kcov.rst
|
||||||
F: include/linux/kcov.h
|
F: include/linux/kcov.h
|
||||||
F: include/uapi/linux/kcov.h
|
F: include/uapi/linux/kcov.h
|
||||||
@@ -12343,6 +12341,7 @@ F: include/linux/randomize_kstack.h
|
|||||||
F: kernel/configs/hardening.config
|
F: kernel/configs/hardening.config
|
||||||
F: lib/usercopy_kunit.c
|
F: lib/usercopy_kunit.c
|
||||||
F: mm/usercopy.c
|
F: mm/usercopy.c
|
||||||
|
F: security/Kconfig.hardening
|
||||||
K: \b(add|choose)_random_kstack_offset\b
|
K: \b(add|choose)_random_kstack_offset\b
|
||||||
K: \b__check_(object_size|heap_object)\b
|
K: \b__check_(object_size|heap_object)\b
|
||||||
K: \b__counted_by\b
|
K: \b__counted_by\b
|
||||||
@@ -12459,7 +12458,7 @@ F: virt/kvm/*
|
|||||||
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
|
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
|
||||||
M: Marc Zyngier <maz@kernel.org>
|
M: Marc Zyngier <maz@kernel.org>
|
||||||
M: Oliver Upton <oliver.upton@linux.dev>
|
M: Oliver Upton <oliver.upton@linux.dev>
|
||||||
R: James Morse <james.morse@arm.com>
|
R: Joey Gouly <joey.gouly@arm.com>
|
||||||
R: Suzuki K Poulose <suzuki.poulose@arm.com>
|
R: Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||||
R: Zenghui Yu <yuzenghui@huawei.com>
|
R: Zenghui Yu <yuzenghui@huawei.com>
|
||||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||||
@@ -12940,49 +12939,29 @@ LIBATA PATA ARASAN COMPACT FLASH CONTROLLER
|
|||||||
M: Viresh Kumar <vireshk@kernel.org>
|
M: Viresh Kumar <vireshk@kernel.org>
|
||||||
L: linux-ide@vger.kernel.org
|
L: linux-ide@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
|
|
||||||
F: drivers/ata/pata_arasan_cf.c
|
F: drivers/ata/pata_arasan_cf.c
|
||||||
F: include/linux/pata_arasan_cf_data.h
|
F: include/linux/pata_arasan_cf_data.h
|
||||||
|
|
||||||
LIBATA PATA DRIVERS
|
|
||||||
R: Sergey Shtylyov <s.shtylyov@omp.ru>
|
|
||||||
L: linux-ide@vger.kernel.org
|
|
||||||
F: drivers/ata/ata_*.c
|
|
||||||
F: drivers/ata/pata_*.c
|
|
||||||
|
|
||||||
LIBATA PATA FARADAY FTIDE010 AND GEMINI SATA BRIDGE DRIVERS
|
LIBATA PATA FARADAY FTIDE010 AND GEMINI SATA BRIDGE DRIVERS
|
||||||
M: Linus Walleij <linus.walleij@linaro.org>
|
M: Linus Walleij <linus.walleij@linaro.org>
|
||||||
L: linux-ide@vger.kernel.org
|
L: linux-ide@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
|
|
||||||
F: drivers/ata/pata_ftide010.c
|
F: drivers/ata/pata_ftide010.c
|
||||||
F: drivers/ata/sata_gemini.c
|
F: drivers/ata/sata_gemini.c
|
||||||
F: drivers/ata/sata_gemini.h
|
F: drivers/ata/sata_gemini.h
|
||||||
|
|
||||||
LIBATA SATA AHCI PLATFORM devices support
|
LIBATA SATA AHCI PLATFORM devices support
|
||||||
M: Hans de Goede <hdegoede@redhat.com>
|
M: Hans de Goede <hdegoede@redhat.com>
|
||||||
M: Jens Axboe <axboe@kernel.dk>
|
|
||||||
L: linux-ide@vger.kernel.org
|
L: linux-ide@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
|
|
||||||
F: drivers/ata/ahci_platform.c
|
F: drivers/ata/ahci_platform.c
|
||||||
F: drivers/ata/libahci_platform.c
|
F: drivers/ata/libahci_platform.c
|
||||||
F: include/linux/ahci_platform.h
|
F: include/linux/ahci_platform.h
|
||||||
|
|
||||||
LIBATA SATA AHCI SYNOPSYS DWC CONTROLLER DRIVER
|
|
||||||
M: Serge Semin <fancer.lancer@gmail.com>
|
|
||||||
L: linux-ide@vger.kernel.org
|
|
||||||
S: Maintained
|
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata.git
|
|
||||||
F: Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
|
|
||||||
F: Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
|
|
||||||
F: drivers/ata/ahci_dwc.c
|
|
||||||
|
|
||||||
LIBATA SATA PROMISE TX2/TX4 CONTROLLER DRIVER
|
LIBATA SATA PROMISE TX2/TX4 CONTROLLER DRIVER
|
||||||
M: Mikael Pettersson <mikpelinux@gmail.com>
|
M: Mikael Pettersson <mikpelinux@gmail.com>
|
||||||
L: linux-ide@vger.kernel.org
|
L: linux-ide@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
|
|
||||||
F: drivers/ata/sata_promise.*
|
F: drivers/ata/sata_promise.*
|
||||||
|
|
||||||
LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)
|
LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)
|
||||||
@@ -13952,7 +13931,7 @@ F: drivers/media/i2c/max96717.c
|
|||||||
|
|
||||||
MAX9860 MONO AUDIO VOICE CODEC DRIVER
|
MAX9860 MONO AUDIO VOICE CODEC DRIVER
|
||||||
M: Peter Rosin <peda@axentia.se>
|
M: Peter Rosin <peda@axentia.se>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/max9860.txt
|
F: Documentation/devicetree/bindings/sound/max9860.txt
|
||||||
F: sound/soc/codecs/max9860.*
|
F: sound/soc/codecs/max9860.*
|
||||||
@@ -14175,8 +14154,7 @@ T: git git://linuxtv.org/media_tree.git
|
|||||||
F: drivers/media/platform/nxp/imx-pxp.[ch]
|
F: drivers/media/platform/nxp/imx-pxp.[ch]
|
||||||
|
|
||||||
MEDIA DRIVERS FOR ASCOT2E
|
MEDIA DRIVERS FOR ASCOT2E
|
||||||
M: Sergey Kozlov <serjk@netup.ru>
|
M: Abylay Ospan <aospan@amazon.com>
|
||||||
M: Abylay Ospan <aospan@netup.ru>
|
|
||||||
L: linux-media@vger.kernel.org
|
L: linux-media@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
W: https://linuxtv.org
|
W: https://linuxtv.org
|
||||||
@@ -14193,8 +14171,7 @@ T: git git://linuxtv.org/media_tree.git
|
|||||||
F: drivers/media/dvb-frontends/cxd2099*
|
F: drivers/media/dvb-frontends/cxd2099*
|
||||||
|
|
||||||
MEDIA DRIVERS FOR CXD2841ER
|
MEDIA DRIVERS FOR CXD2841ER
|
||||||
M: Sergey Kozlov <serjk@netup.ru>
|
M: Abylay Ospan <aospan@amazon.com>
|
||||||
M: Abylay Ospan <aospan@netup.ru>
|
|
||||||
L: linux-media@vger.kernel.org
|
L: linux-media@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
W: https://linuxtv.org
|
W: https://linuxtv.org
|
||||||
@@ -14247,7 +14224,7 @@ F: drivers/media/platform/nxp/imx7-media-csi.c
|
|||||||
F: drivers/media/platform/nxp/imx8mq-mipi-csi2.c
|
F: drivers/media/platform/nxp/imx8mq-mipi-csi2.c
|
||||||
|
|
||||||
MEDIA DRIVERS FOR HELENE
|
MEDIA DRIVERS FOR HELENE
|
||||||
M: Abylay Ospan <aospan@netup.ru>
|
M: Abylay Ospan <aospan@amazon.com>
|
||||||
L: linux-media@vger.kernel.org
|
L: linux-media@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
W: https://linuxtv.org
|
W: https://linuxtv.org
|
||||||
@@ -14256,8 +14233,7 @@ T: git git://linuxtv.org/media_tree.git
|
|||||||
F: drivers/media/dvb-frontends/helene*
|
F: drivers/media/dvb-frontends/helene*
|
||||||
|
|
||||||
MEDIA DRIVERS FOR HORUS3A
|
MEDIA DRIVERS FOR HORUS3A
|
||||||
M: Sergey Kozlov <serjk@netup.ru>
|
M: Abylay Ospan <aospan@amazon.com>
|
||||||
M: Abylay Ospan <aospan@netup.ru>
|
|
||||||
L: linux-media@vger.kernel.org
|
L: linux-media@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
W: https://linuxtv.org
|
W: https://linuxtv.org
|
||||||
@@ -14266,8 +14242,7 @@ T: git git://linuxtv.org/media_tree.git
|
|||||||
F: drivers/media/dvb-frontends/horus3a*
|
F: drivers/media/dvb-frontends/horus3a*
|
||||||
|
|
||||||
MEDIA DRIVERS FOR LNBH25
|
MEDIA DRIVERS FOR LNBH25
|
||||||
M: Sergey Kozlov <serjk@netup.ru>
|
M: Abylay Ospan <aospan@amazon.com>
|
||||||
M: Abylay Ospan <aospan@netup.ru>
|
|
||||||
L: linux-media@vger.kernel.org
|
L: linux-media@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
W: https://linuxtv.org
|
W: https://linuxtv.org
|
||||||
@@ -14283,8 +14258,7 @@ T: git git://linuxtv.org/media_tree.git
|
|||||||
F: drivers/media/dvb-frontends/mxl5xx*
|
F: drivers/media/dvb-frontends/mxl5xx*
|
||||||
|
|
||||||
MEDIA DRIVERS FOR NETUP PCI UNIVERSAL DVB devices
|
MEDIA DRIVERS FOR NETUP PCI UNIVERSAL DVB devices
|
||||||
M: Sergey Kozlov <serjk@netup.ru>
|
M: Abylay Ospan <aospan@amazon.com>
|
||||||
M: Abylay Ospan <aospan@netup.ru>
|
|
||||||
L: linux-media@vger.kernel.org
|
L: linux-media@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
W: https://linuxtv.org
|
W: https://linuxtv.org
|
||||||
@@ -14909,9 +14883,10 @@ N: include/linux/page[-_]*
|
|||||||
|
|
||||||
MEMORY MAPPING
|
MEMORY MAPPING
|
||||||
M: Andrew Morton <akpm@linux-foundation.org>
|
M: Andrew Morton <akpm@linux-foundation.org>
|
||||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
M: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||||
|
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||||
R: Vlastimil Babka <vbabka@suse.cz>
|
R: Vlastimil Babka <vbabka@suse.cz>
|
||||||
R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
R: Jann Horn <jannh@google.com>
|
||||||
L: linux-mm@kvack.org
|
L: linux-mm@kvack.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
W: http://www.linux-mm.org
|
W: http://www.linux-mm.org
|
||||||
@@ -14934,13 +14909,6 @@ F: drivers/mtd/
|
|||||||
F: include/linux/mtd/
|
F: include/linux/mtd/
|
||||||
F: include/uapi/mtd/
|
F: include/uapi/mtd/
|
||||||
|
|
||||||
MEMSENSING MICROSYSTEMS MSA311 DRIVER
|
|
||||||
M: Dmitry Rokosov <ddrokosov@sberdevices.ru>
|
|
||||||
L: linux-iio@vger.kernel.org
|
|
||||||
S: Maintained
|
|
||||||
F: Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml
|
|
||||||
F: drivers/iio/accel/msa311.c
|
|
||||||
|
|
||||||
MEN A21 WATCHDOG DRIVER
|
MEN A21 WATCHDOG DRIVER
|
||||||
M: Johannes Thumshirn <morbidrsa@gmail.com>
|
M: Johannes Thumshirn <morbidrsa@gmail.com>
|
||||||
L: linux-watchdog@vger.kernel.org
|
L: linux-watchdog@vger.kernel.org
|
||||||
@@ -15085,7 +15053,8 @@ F: drivers/spi/spi-at91-usart.c
|
|||||||
|
|
||||||
MICROCHIP AUDIO ASOC DRIVERS
|
MICROCHIP AUDIO ASOC DRIVERS
|
||||||
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
M: Andrei Simion <andrei.simion@microchip.com>
|
||||||
|
L: linux-sound@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: Documentation/devicetree/bindings/sound/atmel*
|
F: Documentation/devicetree/bindings/sound/atmel*
|
||||||
F: Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
|
F: Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
|
||||||
@@ -15193,6 +15162,7 @@ F: include/video/atmel_lcdc.h
|
|||||||
|
|
||||||
MICROCHIP MCP16502 PMIC DRIVER
|
MICROCHIP MCP16502 PMIC DRIVER
|
||||||
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
||||||
|
M: Andrei Simion <andrei.simion@microchip.com>
|
||||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||||
S: Supported
|
S: Supported
|
||||||
F: Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
|
F: Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
|
||||||
@@ -15274,7 +15244,6 @@ F: drivers/tty/serial/8250/8250_pci1xxxx.c
|
|||||||
|
|
||||||
MICROCHIP POLARFIRE FPGA DRIVERS
|
MICROCHIP POLARFIRE FPGA DRIVERS
|
||||||
M: Conor Dooley <conor.dooley@microchip.com>
|
M: Conor Dooley <conor.dooley@microchip.com>
|
||||||
R: Vladimir Georgiev <v.georgiev@metrotek.ru>
|
|
||||||
L: linux-fpga@vger.kernel.org
|
L: linux-fpga@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml
|
F: Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml
|
||||||
@@ -15324,6 +15293,7 @@ F: drivers/spi/spi-atmel.*
|
|||||||
|
|
||||||
MICROCHIP SSC DRIVER
|
MICROCHIP SSC DRIVER
|
||||||
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
||||||
|
M: Andrei Simion <andrei.simion@microchip.com>
|
||||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||||
S: Supported
|
S: Supported
|
||||||
F: Documentation/devicetree/bindings/misc/atmel-ssc.txt
|
F: Documentation/devicetree/bindings/misc/atmel-ssc.txt
|
||||||
@@ -15529,17 +15499,6 @@ F: arch/mips/
|
|||||||
F: drivers/platform/mips/
|
F: drivers/platform/mips/
|
||||||
F: include/dt-bindings/mips/
|
F: include/dt-bindings/mips/
|
||||||
|
|
||||||
MIPS BAIKAL-T1 PLATFORM
|
|
||||||
M: Serge Semin <fancer.lancer@gmail.com>
|
|
||||||
L: linux-mips@vger.kernel.org
|
|
||||||
S: Supported
|
|
||||||
F: Documentation/devicetree/bindings/bus/baikal,bt1-*.yaml
|
|
||||||
F: Documentation/devicetree/bindings/clock/baikal,bt1-*.yaml
|
|
||||||
F: drivers/bus/bt1-*.c
|
|
||||||
F: drivers/clk/baikal-t1/
|
|
||||||
F: drivers/memory/bt1-l2-ctl.c
|
|
||||||
F: drivers/mtd/maps/physmap-bt1-rom.[ch]
|
|
||||||
|
|
||||||
MIPS BOSTON DEVELOPMENT BOARD
|
MIPS BOSTON DEVELOPMENT BOARD
|
||||||
M: Paul Burton <paulburton@kernel.org>
|
M: Paul Burton <paulburton@kernel.org>
|
||||||
L: linux-mips@vger.kernel.org
|
L: linux-mips@vger.kernel.org
|
||||||
@@ -15552,7 +15511,6 @@ F: include/dt-bindings/clock/boston-clock.h
|
|||||||
|
|
||||||
MIPS CORE DRIVERS
|
MIPS CORE DRIVERS
|
||||||
M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
||||||
M: Serge Semin <fancer.lancer@gmail.com>
|
|
||||||
L: linux-mips@vger.kernel.org
|
L: linux-mips@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: drivers/bus/mips_cdmm.c
|
F: drivers/bus/mips_cdmm.c
|
||||||
@@ -15957,7 +15915,7 @@ F: include/linux/mtd/*nand*.h
|
|||||||
|
|
||||||
NATIVE INSTRUMENTS USB SOUND INTERFACE DRIVER
|
NATIVE INSTRUMENTS USB SOUND INTERFACE DRIVER
|
||||||
M: Daniel Mack <zonque@gmail.com>
|
M: Daniel Mack <zonque@gmail.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
W: http://www.native-instruments.com
|
W: http://www.native-instruments.com
|
||||||
F: sound/usb/caiaq/
|
F: sound/usb/caiaq/
|
||||||
@@ -16088,6 +16046,7 @@ F: include/uapi/linux/net_dropmon.h
|
|||||||
F: net/core/drop_monitor.c
|
F: net/core/drop_monitor.c
|
||||||
|
|
||||||
NETWORKING DRIVERS
|
NETWORKING DRIVERS
|
||||||
|
M: Andrew Lunn <andrew+netdev@lunn.ch>
|
||||||
M: "David S. Miller" <davem@davemloft.net>
|
M: "David S. Miller" <davem@davemloft.net>
|
||||||
M: Eric Dumazet <edumazet@google.com>
|
M: Eric Dumazet <edumazet@google.com>
|
||||||
M: Jakub Kicinski <kuba@kernel.org>
|
M: Jakub Kicinski <kuba@kernel.org>
|
||||||
@@ -16153,6 +16112,7 @@ M: "David S. Miller" <davem@davemloft.net>
|
|||||||
M: Eric Dumazet <edumazet@google.com>
|
M: Eric Dumazet <edumazet@google.com>
|
||||||
M: Jakub Kicinski <kuba@kernel.org>
|
M: Jakub Kicinski <kuba@kernel.org>
|
||||||
M: Paolo Abeni <pabeni@redhat.com>
|
M: Paolo Abeni <pabeni@redhat.com>
|
||||||
|
R: Simon Horman <horms@kernel.org>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
P: Documentation/process/maintainer-netdev.rst
|
P: Documentation/process/maintainer-netdev.rst
|
||||||
@@ -16195,10 +16155,22 @@ F: include/uapi/linux/rtnetlink.h
|
|||||||
F: lib/net_utils.c
|
F: lib/net_utils.c
|
||||||
F: lib/random32.c
|
F: lib/random32.c
|
||||||
F: net/
|
F: net/
|
||||||
|
F: samples/pktgen/
|
||||||
F: tools/net/
|
F: tools/net/
|
||||||
F: tools/testing/selftests/net/
|
F: tools/testing/selftests/net/
|
||||||
|
X: Documentation/networking/mac80211-injection.rst
|
||||||
|
X: Documentation/networking/mac80211_hwsim/
|
||||||
|
X: Documentation/networking/regulatory.rst
|
||||||
|
X: include/net/cfg80211.h
|
||||||
|
X: include/net/ieee80211_radiotap.h
|
||||||
|
X: include/net/iw_handler.h
|
||||||
|
X: include/net/mac80211.h
|
||||||
|
X: include/net/wext.h
|
||||||
X: net/9p/
|
X: net/9p/
|
||||||
X: net/bluetooth/
|
X: net/bluetooth/
|
||||||
|
X: net/mac80211/
|
||||||
|
X: net/rfkill/
|
||||||
|
X: net/wireless/
|
||||||
|
|
||||||
NETWORKING [IPSEC]
|
NETWORKING [IPSEC]
|
||||||
M: Steffen Klassert <steffen.klassert@secunet.com>
|
M: Steffen Klassert <steffen.klassert@secunet.com>
|
||||||
@@ -16508,12 +16480,6 @@ F: include/linux/ntb.h
|
|||||||
F: include/linux/ntb_transport.h
|
F: include/linux/ntb_transport.h
|
||||||
F: tools/testing/selftests/ntb/
|
F: tools/testing/selftests/ntb/
|
||||||
|
|
||||||
NTB IDT DRIVER
|
|
||||||
M: Serge Semin <fancer.lancer@gmail.com>
|
|
||||||
L: ntb@lists.linux.dev
|
|
||||||
S: Supported
|
|
||||||
F: drivers/ntb/hw/idt/
|
|
||||||
|
|
||||||
NTB INTEL DRIVER
|
NTB INTEL DRIVER
|
||||||
M: Dave Jiang <dave.jiang@intel.com>
|
M: Dave Jiang <dave.jiang@intel.com>
|
||||||
L: ntb@lists.linux.dev
|
L: ntb@lists.linux.dev
|
||||||
@@ -16728,7 +16694,7 @@ F: drivers/extcon/extcon-ptn5150.c
|
|||||||
|
|
||||||
NXP SGTL5000 DRIVER
|
NXP SGTL5000 DRIVER
|
||||||
M: Fabio Estevam <festevam@gmail.com>
|
M: Fabio Estevam <festevam@gmail.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/fsl,sgtl5000.yaml
|
F: Documentation/devicetree/bindings/sound/fsl,sgtl5000.yaml
|
||||||
F: sound/soc/codecs/sgtl5000*
|
F: sound/soc/codecs/sgtl5000*
|
||||||
@@ -16752,7 +16718,7 @@ K: "nxp,tda998x"
|
|||||||
|
|
||||||
NXP TFA9879 DRIVER
|
NXP TFA9879 DRIVER
|
||||||
M: Peter Rosin <peda@axentia.se>
|
M: Peter Rosin <peda@axentia.se>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/nxp,tfa9879.yaml
|
F: Documentation/devicetree/bindings/sound/nxp,tfa9879.yaml
|
||||||
F: sound/soc/codecs/tfa9879*
|
F: sound/soc/codecs/tfa9879*
|
||||||
@@ -16764,7 +16730,7 @@ F: drivers/nfc/nxp-nci
|
|||||||
|
|
||||||
NXP/Goodix TFA989X (TFA1) DRIVER
|
NXP/Goodix TFA989X (TFA1) DRIVER
|
||||||
M: Stephan Gerhold <stephan@gerhold.net>
|
M: Stephan Gerhold <stephan@gerhold.net>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
|
F: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
|
||||||
F: sound/soc/codecs/tfa989x.c
|
F: sound/soc/codecs/tfa989x.c
|
||||||
@@ -16850,7 +16816,7 @@ F: include/uapi/misc/ocxl.h
|
|||||||
OMAP AUDIO SUPPORT
|
OMAP AUDIO SUPPORT
|
||||||
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||||
M: Jarkko Nikula <jarkko.nikula@bitmer.com>
|
M: Jarkko Nikula <jarkko.nikula@bitmer.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
L: linux-omap@vger.kernel.org
|
L: linux-omap@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: sound/soc/ti/n810.c
|
F: sound/soc/ti/n810.c
|
||||||
@@ -17407,7 +17373,7 @@ F: include/linux/pm_opp.h
|
|||||||
|
|
||||||
OPL4 DRIVER
|
OPL4 DRIVER
|
||||||
M: Clemens Ladisch <clemens@ladisch.de>
|
M: Clemens Ladisch <clemens@ladisch.de>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||||
F: sound/drivers/opl4/
|
F: sound/drivers/opl4/
|
||||||
@@ -18534,13 +18500,6 @@ F: drivers/pps/
|
|||||||
F: include/linux/pps*.h
|
F: include/linux/pps*.h
|
||||||
F: include/uapi/linux/pps.h
|
F: include/uapi/linux/pps.h
|
||||||
|
|
||||||
PPTP DRIVER
|
|
||||||
M: Dmitry Kozlov <xeb@mail.ru>
|
|
||||||
L: netdev@vger.kernel.org
|
|
||||||
S: Maintained
|
|
||||||
W: http://sourceforge.net/projects/accel-pptp
|
|
||||||
F: drivers/net/ppp/pptp.c
|
|
||||||
|
|
||||||
PRESSURE STALL INFORMATION (PSI)
|
PRESSURE STALL INFORMATION (PSI)
|
||||||
M: Johannes Weiner <hannes@cmpxchg.org>
|
M: Johannes Weiner <hannes@cmpxchg.org>
|
||||||
M: Suren Baghdasaryan <surenb@google.com>
|
M: Suren Baghdasaryan <surenb@google.com>
|
||||||
@@ -18790,7 +18749,7 @@ F: drivers/crypto/intel/qat/
|
|||||||
|
|
||||||
QCOM AUDIO (ASoC) DRIVERS
|
QCOM AUDIO (ASoC) DRIVERS
|
||||||
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
L: linux-arm-msm@vger.kernel.org
|
L: linux-arm-msm@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: Documentation/devicetree/bindings/soc/qcom/qcom,apr*
|
F: Documentation/devicetree/bindings/soc/qcom/qcom,apr*
|
||||||
@@ -19514,6 +19473,14 @@ S: Maintained
|
|||||||
F: Documentation/tools/rtla/
|
F: Documentation/tools/rtla/
|
||||||
F: tools/tracing/rtla/
|
F: tools/tracing/rtla/
|
||||||
|
|
||||||
|
Real-time Linux (PREEMPT_RT)
|
||||||
|
M: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
|
||||||
|
M: Clark Williams <clrkwllms@kernel.org>
|
||||||
|
M: Steven Rostedt <rostedt@goodmis.org>
|
||||||
|
L: linux-rt-devel@lists.linux.dev
|
||||||
|
S: Supported
|
||||||
|
K: PREEMPT_RT
|
||||||
|
|
||||||
REALTEK AUDIO CODECS
|
REALTEK AUDIO CODECS
|
||||||
M: Oder Chiou <oder_chiou@realtek.com>
|
M: Oder Chiou <oder_chiou@realtek.com>
|
||||||
S: Maintained
|
S: Maintained
|
||||||
@@ -19623,15 +19590,6 @@ S: Supported
|
|||||||
F: Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml
|
F: Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml
|
||||||
F: drivers/i2c/busses/i2c-emev2.c
|
F: drivers/i2c/busses/i2c-emev2.c
|
||||||
|
|
||||||
RENESAS ETHERNET AVB DRIVER
|
|
||||||
R: Sergey Shtylyov <s.shtylyov@omp.ru>
|
|
||||||
L: netdev@vger.kernel.org
|
|
||||||
L: linux-renesas-soc@vger.kernel.org
|
|
||||||
F: Documentation/devicetree/bindings/net/renesas,etheravb.yaml
|
|
||||||
F: drivers/net/ethernet/renesas/Kconfig
|
|
||||||
F: drivers/net/ethernet/renesas/Makefile
|
|
||||||
F: drivers/net/ethernet/renesas/ravb*
|
|
||||||
|
|
||||||
RENESAS ETHERNET SWITCH DRIVER
|
RENESAS ETHERNET SWITCH DRIVER
|
||||||
R: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
R: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
@@ -19652,7 +19610,7 @@ F: drivers/net/ethernet/renesas/rtsn.*
|
|||||||
|
|
||||||
RENESAS IDT821034 ASoC CODEC
|
RENESAS IDT821034 ASoC CODEC
|
||||||
M: Herve Codina <herve.codina@bootlin.com>
|
M: Herve Codina <herve.codina@bootlin.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/renesas,idt821034.yaml
|
F: Documentation/devicetree/bindings/sound/renesas,idt821034.yaml
|
||||||
F: sound/soc/codecs/idt821034.c
|
F: sound/soc/codecs/idt821034.c
|
||||||
@@ -19681,14 +19639,6 @@ F: Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml
|
|||||||
F: drivers/i2c/busses/i2c-rcar.c
|
F: drivers/i2c/busses/i2c-rcar.c
|
||||||
F: drivers/i2c/busses/i2c-sh_mobile.c
|
F: drivers/i2c/busses/i2c-sh_mobile.c
|
||||||
|
|
||||||
RENESAS R-CAR SATA DRIVER
|
|
||||||
R: Sergey Shtylyov <s.shtylyov@omp.ru>
|
|
||||||
L: linux-ide@vger.kernel.org
|
|
||||||
L: linux-renesas-soc@vger.kernel.org
|
|
||||||
S: Supported
|
|
||||||
F: Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
|
|
||||||
F: drivers/ata/sata_rcar.c
|
|
||||||
|
|
||||||
RENESAS R-CAR THERMAL DRIVERS
|
RENESAS R-CAR THERMAL DRIVERS
|
||||||
M: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
M: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
||||||
L: linux-renesas-soc@vger.kernel.org
|
L: linux-renesas-soc@vger.kernel.org
|
||||||
@@ -19764,16 +19714,6 @@ S: Supported
|
|||||||
F: Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml
|
F: Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml
|
||||||
F: drivers/i2c/busses/i2c-rzv2m.c
|
F: drivers/i2c/busses/i2c-rzv2m.c
|
||||||
|
|
||||||
RENESAS SUPERH ETHERNET DRIVER
|
|
||||||
R: Sergey Shtylyov <s.shtylyov@omp.ru>
|
|
||||||
L: netdev@vger.kernel.org
|
|
||||||
L: linux-renesas-soc@vger.kernel.org
|
|
||||||
F: Documentation/devicetree/bindings/net/renesas,ether.yaml
|
|
||||||
F: drivers/net/ethernet/renesas/Kconfig
|
|
||||||
F: drivers/net/ethernet/renesas/Makefile
|
|
||||||
F: drivers/net/ethernet/renesas/sh_eth*
|
|
||||||
F: include/linux/sh_eth.h
|
|
||||||
|
|
||||||
RENESAS USB PHY DRIVER
|
RENESAS USB PHY DRIVER
|
||||||
M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
||||||
L: linux-renesas-soc@vger.kernel.org
|
L: linux-renesas-soc@vger.kernel.org
|
||||||
@@ -20403,7 +20343,7 @@ F: security/safesetid/
|
|||||||
|
|
||||||
SAMSUNG AUDIO (ASoC) DRIVERS
|
SAMSUNG AUDIO (ASoC) DRIVERS
|
||||||
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
B: mailto:linux-samsung-soc@vger.kernel.org
|
B: mailto:linux-samsung-soc@vger.kernel.org
|
||||||
F: Documentation/devicetree/bindings/sound/samsung*
|
F: Documentation/devicetree/bindings/sound/samsung*
|
||||||
@@ -20939,7 +20879,7 @@ F: drivers/media/rc/serial_ir.c
|
|||||||
|
|
||||||
SERIAL LOW-POWER INTER-CHIP MEDIA BUS (SLIMbus)
|
SERIAL LOW-POWER INTER-CHIP MEDIA BUS (SLIMbus)
|
||||||
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/slimbus/
|
F: Documentation/devicetree/bindings/slimbus/
|
||||||
F: drivers/slimbus/
|
F: drivers/slimbus/
|
||||||
@@ -21373,7 +21313,7 @@ F: Documentation/devicetree/bindings/i2c/socionext,synquacer-i2c.yaml
|
|||||||
F: drivers/i2c/busses/i2c-synquacer.c
|
F: drivers/i2c/busses/i2c-synquacer.c
|
||||||
|
|
||||||
SOCIONEXT UNIPHIER SOUND DRIVER
|
SOCIONEXT UNIPHIER SOUND DRIVER
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Orphan
|
S: Orphan
|
||||||
F: sound/soc/uniphier/
|
F: sound/soc/uniphier/
|
||||||
|
|
||||||
@@ -21632,7 +21572,7 @@ F: tools/testing/selftests/alsa
|
|||||||
|
|
||||||
SOUND - COMPRESSED AUDIO
|
SOUND - COMPRESSED AUDIO
|
||||||
M: Vinod Koul <vkoul@kernel.org>
|
M: Vinod Koul <vkoul@kernel.org>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||||
F: Documentation/sound/designs/compress-offload.rst
|
F: Documentation/sound/designs/compress-offload.rst
|
||||||
@@ -21695,7 +21635,7 @@ M: Vinod Koul <vkoul@kernel.org>
|
|||||||
M: Bard Liao <yung-chuan.liao@linux.intel.com>
|
M: Bard Liao <yung-chuan.liao@linux.intel.com>
|
||||||
R: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
|
R: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
|
||||||
R: Sanyog Kale <sanyog.r.kale@intel.com>
|
R: Sanyog Kale <sanyog.r.kale@intel.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git
|
||||||
F: Documentation/driver-api/soundwire/
|
F: Documentation/driver-api/soundwire/
|
||||||
@@ -21768,8 +21708,8 @@ F: drivers/accessibility/speakup/
|
|||||||
SPEAR PLATFORM/CLOCK/PINCTRL SUPPORT
|
SPEAR PLATFORM/CLOCK/PINCTRL SUPPORT
|
||||||
M: Viresh Kumar <vireshk@kernel.org>
|
M: Viresh Kumar <vireshk@kernel.org>
|
||||||
M: Shiraz Hashim <shiraz.linux.kernel@gmail.com>
|
M: Shiraz Hashim <shiraz.linux.kernel@gmail.com>
|
||||||
M: soc@kernel.org
|
|
||||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||||
|
L: soc@lists.linux.dev
|
||||||
S: Maintained
|
S: Maintained
|
||||||
W: http://www.st.com/spear
|
W: http://www.st.com/spear
|
||||||
F: arch/arm/boot/dts/st/spear*
|
F: arch/arm/boot/dts/st/spear*
|
||||||
@@ -22168,7 +22108,7 @@ F: kernel/static_call.c
|
|||||||
|
|
||||||
STI AUDIO (ASoC) DRIVERS
|
STI AUDIO (ASoC) DRIVERS
|
||||||
M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
|
M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt
|
F: Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt
|
||||||
F: sound/soc/sti/
|
F: sound/soc/sti/
|
||||||
@@ -22189,7 +22129,7 @@ F: drivers/media/usb/stk1160/
|
|||||||
STM32 AUDIO (ASoC) DRIVERS
|
STM32 AUDIO (ASoC) DRIVERS
|
||||||
M: Olivier Moysan <olivier.moysan@foss.st.com>
|
M: Olivier Moysan <olivier.moysan@foss.st.com>
|
||||||
M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
|
M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
|
F: Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
|
||||||
F: Documentation/devicetree/bindings/sound/st,stm32-*.yaml
|
F: Documentation/devicetree/bindings/sound/st,stm32-*.yaml
|
||||||
@@ -22427,19 +22367,11 @@ F: drivers/tty/serial/8250/8250_lpss.c
|
|||||||
|
|
||||||
SYNOPSYS DESIGNWARE APB GPIO DRIVER
|
SYNOPSYS DESIGNWARE APB GPIO DRIVER
|
||||||
M: Hoan Tran <hoan@os.amperecomputing.com>
|
M: Hoan Tran <hoan@os.amperecomputing.com>
|
||||||
M: Serge Semin <fancer.lancer@gmail.com>
|
|
||||||
L: linux-gpio@vger.kernel.org
|
L: linux-gpio@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
|
F: Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
|
||||||
F: drivers/gpio/gpio-dwapb.c
|
F: drivers/gpio/gpio-dwapb.c
|
||||||
|
|
||||||
SYNOPSYS DESIGNWARE APB SSI DRIVER
|
|
||||||
M: Serge Semin <fancer.lancer@gmail.com>
|
|
||||||
L: linux-spi@vger.kernel.org
|
|
||||||
S: Supported
|
|
||||||
F: Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
|
|
||||||
F: drivers/spi/spi-dw*
|
|
||||||
|
|
||||||
SYNOPSYS DESIGNWARE AXI DMAC DRIVER
|
SYNOPSYS DESIGNWARE AXI DMAC DRIVER
|
||||||
M: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
|
M: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
|
||||||
S: Maintained
|
S: Maintained
|
||||||
@@ -22892,7 +22824,7 @@ F: drivers/irqchip/irq-xtensa-*
|
|||||||
|
|
||||||
TEXAS INSTRUMENTS ASoC DRIVERS
|
TEXAS INSTRUMENTS ASoC DRIVERS
|
||||||
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml
|
F: Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml
|
||||||
F: sound/soc/ti/
|
F: sound/soc/ti/
|
||||||
@@ -22901,7 +22833,7 @@ TEXAS INSTRUMENTS AUDIO (ASoC/HDA) DRIVERS
|
|||||||
M: Shenghao Ding <shenghao-ding@ti.com>
|
M: Shenghao Ding <shenghao-ding@ti.com>
|
||||||
M: Kevin Lu <kevin-lu@ti.com>
|
M: Kevin Lu <kevin-lu@ti.com>
|
||||||
M: Baojun Xu <baojun.xu@ti.com>
|
M: Baojun Xu <baojun.xu@ti.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/tas2552.txt
|
F: Documentation/devicetree/bindings/sound/tas2552.txt
|
||||||
F: Documentation/devicetree/bindings/sound/ti,tas2562.yaml
|
F: Documentation/devicetree/bindings/sound/ti,tas2562.yaml
|
||||||
@@ -23269,7 +23201,7 @@ F: drivers/soc/ti/*
|
|||||||
TI LM49xxx FAMILY ASoC CODEC DRIVERS
|
TI LM49xxx FAMILY ASoC CODEC DRIVERS
|
||||||
M: M R Swami Reddy <mr.swami.reddy@ti.com>
|
M: M R Swami Reddy <mr.swami.reddy@ti.com>
|
||||||
M: Vishwas A Deshpande <vishwas.a.deshpande@ti.com>
|
M: Vishwas A Deshpande <vishwas.a.deshpande@ti.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: sound/soc/codecs/isabelle*
|
F: sound/soc/codecs/isabelle*
|
||||||
F: sound/soc/codecs/lm49453*
|
F: sound/soc/codecs/lm49453*
|
||||||
@@ -23283,15 +23215,15 @@ F: Documentation/devicetree/bindings/iio/adc/ti,lmp92064.yaml
|
|||||||
F: drivers/iio/adc/ti-lmp92064.c
|
F: drivers/iio/adc/ti-lmp92064.c
|
||||||
|
|
||||||
TI PCM3060 ASoC CODEC DRIVER
|
TI PCM3060 ASoC CODEC DRIVER
|
||||||
M: Kirill Marinushkin <kmarinushkin@birdec.com>
|
M: Kirill Marinushkin <k.marinushkin@gmail.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/devicetree/bindings/sound/pcm3060.txt
|
F: Documentation/devicetree/bindings/sound/pcm3060.txt
|
||||||
F: sound/soc/codecs/pcm3060*
|
F: sound/soc/codecs/pcm3060*
|
||||||
|
|
||||||
TI TAS571X FAMILY ASoC CODEC DRIVER
|
TI TAS571X FAMILY ASoC CODEC DRIVER
|
||||||
M: Kevin Cernekee <cernekee@chromium.org>
|
M: Kevin Cernekee <cernekee@chromium.org>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Odd Fixes
|
S: Odd Fixes
|
||||||
F: sound/soc/codecs/tas571x*
|
F: sound/soc/codecs/tas571x*
|
||||||
|
|
||||||
@@ -23319,7 +23251,7 @@ F: drivers/iio/adc/ti-tsc2046.c
|
|||||||
|
|
||||||
TI TWL4030 SERIES SOC CODEC DRIVER
|
TI TWL4030 SERIES SOC CODEC DRIVER
|
||||||
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: sound/soc/codecs/twl4030*
|
F: sound/soc/codecs/twl4030*
|
||||||
|
|
||||||
@@ -23749,12 +23681,6 @@ L: linux-input@vger.kernel.org
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/hid/hid-udraw-ps3.c
|
F: drivers/hid/hid-udraw-ps3.c
|
||||||
|
|
||||||
UFS FILESYSTEM
|
|
||||||
M: Evgeniy Dushistov <dushistov@mail.ru>
|
|
||||||
S: Maintained
|
|
||||||
F: Documentation/admin-guide/ufs.rst
|
|
||||||
F: fs/ufs/
|
|
||||||
|
|
||||||
UHID USERSPACE HID IO DRIVER
|
UHID USERSPACE HID IO DRIVER
|
||||||
M: David Rheinsberg <david@readahead.eu>
|
M: David Rheinsberg <david@readahead.eu>
|
||||||
L: linux-input@vger.kernel.org
|
L: linux-input@vger.kernel.org
|
||||||
@@ -23995,7 +23921,7 @@ F: drivers/usb/storage/
|
|||||||
|
|
||||||
USB MIDI DRIVER
|
USB MIDI DRIVER
|
||||||
M: Clemens Ladisch <clemens@ladisch.de>
|
M: Clemens Ladisch <clemens@ladisch.de>
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||||
F: sound/usb/midi.*
|
F: sound/usb/midi.*
|
||||||
@@ -24057,6 +23983,7 @@ USB RAW GADGET DRIVER
|
|||||||
R: Andrey Konovalov <andreyknvl@gmail.com>
|
R: Andrey Konovalov <andreyknvl@gmail.com>
|
||||||
L: linux-usb@vger.kernel.org
|
L: linux-usb@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
|
B: https://github.com/xairy/raw-gadget/issues
|
||||||
F: Documentation/usb/raw-gadget.rst
|
F: Documentation/usb/raw-gadget.rst
|
||||||
F: drivers/usb/gadget/legacy/raw_gadget.c
|
F: drivers/usb/gadget/legacy/raw_gadget.c
|
||||||
F: include/uapi/linux/usb/raw_gadget.h
|
F: include/uapi/linux/usb/raw_gadget.h
|
||||||
@@ -24173,8 +24100,12 @@ F: drivers/usb/host/xhci*
|
|||||||
|
|
||||||
USER DATAGRAM PROTOCOL (UDP)
|
USER DATAGRAM PROTOCOL (UDP)
|
||||||
M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
|
M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
|
||||||
|
L: netdev@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: include/linux/udp.h
|
F: include/linux/udp.h
|
||||||
|
F: include/net/udp.h
|
||||||
|
F: include/trace/events/udp.h
|
||||||
|
F: include/uapi/linux/udp.h
|
||||||
F: net/ipv4/udp.c
|
F: net/ipv4/udp.c
|
||||||
F: net/ipv6/udp.c
|
F: net/ipv6/udp.c
|
||||||
|
|
||||||
@@ -24201,6 +24132,7 @@ F: lib/iov_iter.c
|
|||||||
|
|
||||||
USERSPACE DMA BUFFER DRIVER
|
USERSPACE DMA BUFFER DRIVER
|
||||||
M: Gerd Hoffmann <kraxel@redhat.com>
|
M: Gerd Hoffmann <kraxel@redhat.com>
|
||||||
|
M: Vivek Kasireddy <vivek.kasireddy@intel.com>
|
||||||
L: dri-devel@lists.freedesktop.org
|
L: dri-devel@lists.freedesktop.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||||
@@ -24655,7 +24587,7 @@ VIRTIO SOUND DRIVER
|
|||||||
M: Anton Yakovlev <anton.yakovlev@opensynergy.com>
|
M: Anton Yakovlev <anton.yakovlev@opensynergy.com>
|
||||||
M: "Michael S. Tsirkin" <mst@redhat.com>
|
M: "Michael S. Tsirkin" <mst@redhat.com>
|
||||||
L: virtualization@lists.linux.dev
|
L: virtualization@lists.linux.dev
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: include/uapi/linux/virtio_snd.h
|
F: include/uapi/linux/virtio_snd.h
|
||||||
F: sound/virtio/*
|
F: sound/virtio/*
|
||||||
@@ -24724,9 +24656,10 @@ F: tools/testing/vsock/
|
|||||||
|
|
||||||
VMA
|
VMA
|
||||||
M: Andrew Morton <akpm@linux-foundation.org>
|
M: Andrew Morton <akpm@linux-foundation.org>
|
||||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
M: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||||
|
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||||
R: Vlastimil Babka <vbabka@suse.cz>
|
R: Vlastimil Babka <vbabka@suse.cz>
|
||||||
R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
R: Jann Horn <jannh@google.com>
|
||||||
L: linux-mm@kvack.org
|
L: linux-mm@kvack.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
W: https://www.linux-mm.org
|
W: https://www.linux-mm.org
|
||||||
@@ -25384,7 +25317,7 @@ F: include/xen/interface/io/usbif.h
|
|||||||
XEN SOUND FRONTEND DRIVER
|
XEN SOUND FRONTEND DRIVER
|
||||||
M: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
|
M: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
|
||||||
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
|
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: linux-sound@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: sound/xen/*
|
F: sound/xen/*
|
||||||
|
|
||||||
@@ -25400,7 +25333,7 @@ F: include/xen/arm/swiotlb-xen.h
|
|||||||
F: include/xen/swiotlb-xen.h
|
F: include/xen/swiotlb-xen.h
|
||||||
|
|
||||||
XFS FILESYSTEM
|
XFS FILESYSTEM
|
||||||
M: Chandan Babu R <chandan.babu@oracle.com>
|
M: Carlos Maiolino <cem@kernel.org>
|
||||||
R: Darrick J. Wong <djwong@kernel.org>
|
R: Darrick J. Wong <djwong@kernel.org>
|
||||||
L: linux-xfs@vger.kernel.org
|
L: linux-xfs@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
|
|||||||
4
Makefile
4
Makefile
@@ -2,7 +2,7 @@
|
|||||||
VERSION = 6
|
VERSION = 6
|
||||||
PATCHLEVEL = 12
|
PATCHLEVEL = 12
|
||||||
SUBLEVEL = 0
|
SUBLEVEL = 0
|
||||||
EXTRAVERSION = -rc1
|
EXTRAVERSION = -rc6
|
||||||
NAME = Baby Opossum Posse
|
NAME = Baby Opossum Posse
|
||||||
|
|
||||||
# *DOCUMENTATION*
|
# *DOCUMENTATION*
|
||||||
@@ -1645,7 +1645,7 @@ help:
|
|||||||
echo '* dtbs - Build device tree blobs for enabled boards'; \
|
echo '* dtbs - Build device tree blobs for enabled boards'; \
|
||||||
echo ' dtbs_install - Install dtbs to $(INSTALL_DTBS_PATH)'; \
|
echo ' dtbs_install - Install dtbs to $(INSTALL_DTBS_PATH)'; \
|
||||||
echo ' dt_binding_check - Validate device tree binding documents and examples'; \
|
echo ' dt_binding_check - Validate device tree binding documents and examples'; \
|
||||||
echo ' dt_binding_schema - Build processed device tree binding schemas'; \
|
echo ' dt_binding_schemas - Build processed device tree binding schemas'; \
|
||||||
echo ' dtbs_check - Validate device tree source files';\
|
echo ' dtbs_check - Validate device tree source files';\
|
||||||
echo '')
|
echo '')
|
||||||
|
|
||||||
|
|||||||
16
arch/Kconfig
16
arch/Kconfig
@@ -838,7 +838,7 @@ config CFI_CLANG
|
|||||||
config CFI_ICALL_NORMALIZE_INTEGERS
|
config CFI_ICALL_NORMALIZE_INTEGERS
|
||||||
bool "Normalize CFI tags for integers"
|
bool "Normalize CFI tags for integers"
|
||||||
depends on CFI_CLANG
|
depends on CFI_CLANG
|
||||||
depends on $(cc-option,-fsanitize=kcfi -fsanitize-cfi-icall-experimental-normalize-integers)
|
depends on HAVE_CFI_ICALL_NORMALIZE_INTEGERS_CLANG
|
||||||
help
|
help
|
||||||
This option normalizes the CFI tags for integer types so that all
|
This option normalizes the CFI tags for integer types so that all
|
||||||
integer types of the same size and signedness receive the same CFI
|
integer types of the same size and signedness receive the same CFI
|
||||||
@@ -851,6 +851,20 @@ config CFI_ICALL_NORMALIZE_INTEGERS
|
|||||||
|
|
||||||
This option is necessary for using CFI with Rust. If unsure, say N.
|
This option is necessary for using CFI with Rust. If unsure, say N.
|
||||||
|
|
||||||
|
config HAVE_CFI_ICALL_NORMALIZE_INTEGERS_CLANG
|
||||||
|
def_bool y
|
||||||
|
depends on $(cc-option,-fsanitize=kcfi -fsanitize-cfi-icall-experimental-normalize-integers)
|
||||||
|
# With GCOV/KASAN we need this fix: https://github.com/llvm/llvm-project/pull/104826
|
||||||
|
depends on CLANG_VERSION >= 190103 || (!GCOV_KERNEL && !KASAN_GENERIC && !KASAN_SW_TAGS)
|
||||||
|
|
||||||
|
config HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC
|
||||||
|
def_bool y
|
||||||
|
depends on HAVE_CFI_ICALL_NORMALIZE_INTEGERS_CLANG
|
||||||
|
depends on RUSTC_VERSION >= 107900
|
||||||
|
# With GCOV/KASAN we need this fix: https://github.com/rust-lang/rust/pull/129373
|
||||||
|
depends on (RUSTC_LLVM_VERSION >= 190103 && RUSTC_VERSION >= 108200) || \
|
||||||
|
(!GCOV_KERNEL && !KASAN_GENERIC && !KASAN_SW_TAGS)
|
||||||
|
|
||||||
config CFI_PERMISSIVE
|
config CFI_PERMISSIVE
|
||||||
bool "Use CFI in permissive mode"
|
bool "Use CFI in permissive mode"
|
||||||
depends on CFI_CLANG
|
depends on CFI_CLANG
|
||||||
|
|||||||
@@ -22,7 +22,7 @@
|
|||||||
|
|
||||||
#include <asm/gentrap.h>
|
#include <asm/gentrap.h>
|
||||||
#include <linux/uaccess.h>
|
#include <linux/uaccess.h>
|
||||||
#include <asm/unaligned.h>
|
#include <linux/unaligned.h>
|
||||||
#include <asm/sysinfo.h>
|
#include <asm/sysinfo.h>
|
||||||
#include <asm/hwrpb.h>
|
#include <asm/hwrpb.h>
|
||||||
#include <asm/mmu_context.h>
|
#include <asm/mmu_context.h>
|
||||||
|
|||||||
@@ -9,7 +9,7 @@
|
|||||||
#include <linux/types.h>
|
#include <linux/types.h>
|
||||||
#include <asm/byteorder.h>
|
#include <asm/byteorder.h>
|
||||||
#include <asm/page.h>
|
#include <asm/page.h>
|
||||||
#include <asm/unaligned.h>
|
#include <linux/unaligned.h>
|
||||||
|
|
||||||
#ifdef CONFIG_ISA_ARCV2
|
#ifdef CONFIG_ISA_ARCV2
|
||||||
#include <asm/barrier.h>
|
#include <asm/barrier.h>
|
||||||
|
|||||||
@@ -14,6 +14,7 @@ typedef struct {
|
|||||||
unsigned long asid[NR_CPUS]; /* 8 bit MMU PID + Generation cycle */
|
unsigned long asid[NR_CPUS]; /* 8 bit MMU PID + Generation cycle */
|
||||||
} mm_context_t;
|
} mm_context_t;
|
||||||
|
|
||||||
|
struct pt_regs;
|
||||||
extern void do_tlb_overlap_fault(unsigned long, unsigned long, struct pt_regs *);
|
extern void do_tlb_overlap_fault(unsigned long, unsigned long, struct pt_regs *);
|
||||||
|
|
||||||
#endif
|
#endif
|
||||||
|
|||||||
@@ -1,27 +0,0 @@
|
|||||||
/* SPDX-License-Identifier: GPL-2.0-only */
|
|
||||||
/*
|
|
||||||
* Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
|
|
||||||
*/
|
|
||||||
|
|
||||||
#ifndef _ASM_ARC_UNALIGNED_H
|
|
||||||
#define _ASM_ARC_UNALIGNED_H
|
|
||||||
|
|
||||||
/* ARC700 can't handle unaligned Data accesses. */
|
|
||||||
|
|
||||||
#include <asm-generic/unaligned.h>
|
|
||||||
#include <asm/ptrace.h>
|
|
||||||
|
|
||||||
#ifdef CONFIG_ARC_EMUL_UNALIGNED
|
|
||||||
int misaligned_fixup(unsigned long address, struct pt_regs *regs,
|
|
||||||
struct callee_regs *cregs);
|
|
||||||
#else
|
|
||||||
static inline int
|
|
||||||
misaligned_fixup(unsigned long address, struct pt_regs *regs,
|
|
||||||
struct callee_regs *cregs)
|
|
||||||
{
|
|
||||||
/* Not fixed */
|
|
||||||
return 1;
|
|
||||||
}
|
|
||||||
#endif
|
|
||||||
|
|
||||||
#endif /* _ASM_ARC_UNALIGNED_H */
|
|
||||||
@@ -18,8 +18,9 @@
|
|||||||
#include <linux/kgdb.h>
|
#include <linux/kgdb.h>
|
||||||
#include <asm/entry.h>
|
#include <asm/entry.h>
|
||||||
#include <asm/setup.h>
|
#include <asm/setup.h>
|
||||||
#include <asm/unaligned.h>
|
#include <linux/unaligned.h>
|
||||||
#include <asm/kprobes.h>
|
#include <asm/kprobes.h>
|
||||||
|
#include "unaligned.h"
|
||||||
|
|
||||||
void die(const char *str, struct pt_regs *regs, unsigned long address)
|
void die(const char *str, struct pt_regs *regs, unsigned long address)
|
||||||
{
|
{
|
||||||
|
|||||||
@@ -12,6 +12,7 @@
|
|||||||
#include <linux/ptrace.h>
|
#include <linux/ptrace.h>
|
||||||
#include <linux/uaccess.h>
|
#include <linux/uaccess.h>
|
||||||
#include <asm/disasm.h>
|
#include <asm/disasm.h>
|
||||||
|
#include "unaligned.h"
|
||||||
|
|
||||||
#ifdef CONFIG_CPU_BIG_ENDIAN
|
#ifdef CONFIG_CPU_BIG_ENDIAN
|
||||||
#define BE 1
|
#define BE 1
|
||||||
|
|||||||
16
arch/arc/kernel/unaligned.h
Normal file
16
arch/arc/kernel/unaligned.h
Normal file
@@ -0,0 +1,16 @@
|
|||||||
|
struct pt_regs;
|
||||||
|
struct callee_regs;
|
||||||
|
|
||||||
|
#ifdef CONFIG_ARC_EMUL_UNALIGNED
|
||||||
|
int misaligned_fixup(unsigned long address, struct pt_regs *regs,
|
||||||
|
struct callee_regs *cregs);
|
||||||
|
#else
|
||||||
|
static inline int
|
||||||
|
misaligned_fixup(unsigned long address, struct pt_regs *regs,
|
||||||
|
struct callee_regs *cregs)
|
||||||
|
{
|
||||||
|
/* Not fixed */
|
||||||
|
return 1;
|
||||||
|
}
|
||||||
|
#endif
|
||||||
|
|
||||||
@@ -19,7 +19,7 @@
|
|||||||
#include <linux/uaccess.h>
|
#include <linux/uaccess.h>
|
||||||
#include <linux/ptrace.h>
|
#include <linux/ptrace.h>
|
||||||
#include <asm/sections.h>
|
#include <asm/sections.h>
|
||||||
#include <asm/unaligned.h>
|
#include <linux/unaligned.h>
|
||||||
#include <asm/unwind.h>
|
#include <asm/unwind.h>
|
||||||
|
|
||||||
extern char __start_unwind[], __end_unwind[];
|
extern char __start_unwind[], __end_unwind[];
|
||||||
|
|||||||
@@ -77,7 +77,7 @@
|
|||||||
};
|
};
|
||||||
|
|
||||||
&hdmi {
|
&hdmi {
|
||||||
hpd-gpios = <&expgpio 1 GPIO_ACTIVE_LOW>;
|
hpd-gpios = <&expgpio 0 GPIO_ACTIVE_LOW>;
|
||||||
power-domains = <&power RPI_POWER_DOMAIN_HDMI>;
|
power-domains = <&power RPI_POWER_DOMAIN_HDMI>;
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|||||||
@@ -8,7 +8,7 @@
|
|||||||
#include <asm/hwcap.h>
|
#include <asm/hwcap.h>
|
||||||
#include <asm/neon.h>
|
#include <asm/neon.h>
|
||||||
#include <asm/simd.h>
|
#include <asm/simd.h>
|
||||||
#include <asm/unaligned.h>
|
#include <linux/unaligned.h>
|
||||||
#include <crypto/aes.h>
|
#include <crypto/aes.h>
|
||||||
#include <crypto/ctr.h>
|
#include <crypto/ctr.h>
|
||||||
#include <crypto/internal/simd.h>
|
#include <crypto/internal/simd.h>
|
||||||
|
|||||||
@@ -18,7 +18,7 @@
|
|||||||
#include <asm/hwcap.h>
|
#include <asm/hwcap.h>
|
||||||
#include <asm/neon.h>
|
#include <asm/neon.h>
|
||||||
#include <asm/simd.h>
|
#include <asm/simd.h>
|
||||||
#include <asm/unaligned.h>
|
#include <linux/unaligned.h>
|
||||||
|
|
||||||
#define PMULL_MIN_LEN 64L /* minimum size of buffer
|
#define PMULL_MIN_LEN 64L /* minimum size of buffer
|
||||||
* for crc32_pmull_le_16 */
|
* for crc32_pmull_le_16 */
|
||||||
|
|||||||
@@ -9,7 +9,7 @@
|
|||||||
#include <asm/hwcap.h>
|
#include <asm/hwcap.h>
|
||||||
#include <asm/neon.h>
|
#include <asm/neon.h>
|
||||||
#include <asm/simd.h>
|
#include <asm/simd.h>
|
||||||
#include <asm/unaligned.h>
|
#include <linux/unaligned.h>
|
||||||
#include <crypto/aes.h>
|
#include <crypto/aes.h>
|
||||||
#include <crypto/gcm.h>
|
#include <crypto/gcm.h>
|
||||||
#include <crypto/b128ops.h>
|
#include <crypto/b128ops.h>
|
||||||
|
|||||||
@@ -8,7 +8,7 @@
|
|||||||
#include <asm/hwcap.h>
|
#include <asm/hwcap.h>
|
||||||
#include <asm/neon.h>
|
#include <asm/neon.h>
|
||||||
#include <asm/simd.h>
|
#include <asm/simd.h>
|
||||||
#include <asm/unaligned.h>
|
#include <linux/unaligned.h>
|
||||||
#include <crypto/algapi.h>
|
#include <crypto/algapi.h>
|
||||||
#include <crypto/internal/hash.h>
|
#include <crypto/internal/hash.h>
|
||||||
#include <crypto/internal/poly1305.h>
|
#include <crypto/internal/poly1305.h>
|
||||||
|
|||||||
@@ -16,7 +16,7 @@
|
|||||||
#include <asm/hwcap.h>
|
#include <asm/hwcap.h>
|
||||||
#include <asm/simd.h>
|
#include <asm/simd.h>
|
||||||
#include <asm/neon.h>
|
#include <asm/neon.h>
|
||||||
#include <asm/unaligned.h>
|
#include <linux/unaligned.h>
|
||||||
|
|
||||||
#include "sha256_glue.h"
|
#include "sha256_glue.h"
|
||||||
|
|
||||||
|
|||||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user