Add nodes for audio codec and sound card, enable the audio serializer
(McASP1) under use and update pinmux.
Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://www.ti.com/lit/zip/sprr459Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20231003-mcasp_am62a-v3-5-2b631ff319ca@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

This patch adds support for TPS6593 PMIC on main I2C0 bus.
This device provides regulators (bucks and LDOs), but also
GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor)
which monitors the SoC error output signal, and a PFSM
(Pre-configurable Finite State Machine) which manages the
operational modes of the PMIC.
Signed-off-by: Julien Panis <jpanis@baylibre.com>
Signed-off-by: Esteban Blanc <eblanc@baylibre.com>
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20231003-mcasp_am62a-v3-4-2b631ff319ca@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

The TLV320AIC3106 audio codec is interfaced on the i2c-1 bus. With the
default rate of 400Khz the i2c register writes fail to sync:

[   36.026387] tlv320aic3x 1-001b: Unable to sync registers 0x16-0x16. -110
[   38.101130] omap_i2c 20010000.i2c: controller timed out

Dropping the rate to 100Khz fixes the issue.

Fixes: 38c4a08c ("arm64: dts: ti: Add support for AM62A7-SK")
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20231003-mcasp_am62a-v3-3-2b631ff319ca@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

VCC_3V3_MAIN is the output of LM5141-Q1, and it serves as an input to
TPS22965DSGT which produces VCC_3V3_SYS. [1]

Link: https://www.ti.com/lit/zip/sprr459 [1]
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Link: https://lore.kernel.org/r/20231003-mcasp_am62a-v3-2-2b631ff319ca@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Same as AM62, AM62A has three instances of McASP which can be used for
transmitting or receiving digital audio in various formats.
Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20231003-mcasp_am62a-v3-1-2b631ff319ca@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Replace the deprecated label property with color/function.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://lore.kernel.org/r/79cb3cdfed19962ce0d4ae558de897695658a81f.1695901360.git.matthias.schiffer@ew.tq-group.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Set the "embedded" chassis-type for the MBaX4XxL.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://lore.kernel.org/r/55bf14afa377b9bbc1d6c4647895c51c018ae761.1695901360.git.matthias.schiffer@ew.tq-group.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

The pin headers X41 and X42 do not have a fixed function. All of these
pins can be assigned to PRG0, but as a default, it makes more sense to
configure them as simple GPIOs, as the MBaX4XxL is a starterkit/evaluation
mainboard.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://lore.kernel.org/r/77c30081154774ce31fc4306474a3afa52b07753.1695901360.git.matthias.schiffer@ew.tq-group.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Describes the hardware better, and avoids a few warnings during boot:

    lm75 0-004a: supply vs not found, using dummy regulator
    at24 0-0050: supply vcc not found, using dummy regulator
    at24 0-0054: supply vcc not found, using dummy regulator
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://lore.kernel.org/r/d5991041263c96c798b94c0844a1550e28daa3b1.1695901360.git.matthias.schiffer@ew.tq-group.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

AM68 Starter kit has a USB3 hub that connects to the SerDes0 Lane 2.
Update the SerDes configuration to support USB3.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Link: https://lore.kernel.org/r/20230921100039.19897-4-r-gunasekaran@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

AM68 Starter kit features with one PCIe M.2 Key M connector
interfaced via two SerDes lanes. Update the SerDes configuration
for PCIe.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Link: https://lore.kernel.org/r/20230921100039.19897-3-r-gunasekaran@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Lanes 0 and 2 of the J721S2 SerDes WIZ are reserved for USB type-C
lane swap. Update the macro definition for it.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230921100039.19897-2-r-gunasekaran@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Two carveout reserved memory nodes each have been added for each of the
C71x DSP for the TI K3 AM69 SK boards. These nodes are assigned to the
respective rproc device nodes as well. The first region will be used as
the DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.

The current carveout addresses and sizes are defined statically for each
device. The C71x DSP processor supports a MMU called CMMU, but is not
currently supported and as such requires the exact memory used by the
firmware to be set-aside.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20231001181417.743306-10-a-nandan@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Two carveout reserved memory nodes each have been added for each of the
R5F remote processor device within both the MCU and MAIN domains for the
TI K3 AM69 SK boards. These nodes are assigned to the respective rproc
device nodes as well. The first region will be used as the DMA pool for
the rproc device, and the second region will furnish the static carveout
regions for the firmware memory.

The current carveout addresses and sizes are defined statically for each
device. The R5F processors do not have an MMU, and as such require the
exact memory used by the firmwares to be set-aside. The firmware images
do not require any RSC_CARVEOUT entries in their resource tables either
to allocate the memory for firmware memory segments.

Note that the R5F1 carveouts are needed only if the R5F cluster is
running in Split (non-LockStep) mode. The reserved memory nodes can be
disabled later on if there is no use-case defined to use the corresponding
remote processor.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20231001181417.743306-9-a-nandan@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Two carveout reserved memory nodes each have been added for each of the
C71x DSP for the TI K3 AM68 SK boards. These nodes are assigned to the
respective rproc device nodes as well. The first region will be used as
the DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.

The current carveout addresses and sizes are defined statically for each
device. The C71x DSP processor supports a MMU called CMMU, but is not
currently supported and as such requires the exact memory used by the
firmware to be set-aside.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20231001181417.743306-8-a-nandan@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Two carveout reserved memory nodes each have been added for each of the
R5F remote processor device within both the MCU and MAIN domains for the
TI K3 AM68 SK boards. These nodes are assigned to the respective rproc
device nodes as well. The first region will be used as the DMA pool for
the rproc device, and the second region will furnish the static carveout
regions for the firmware memory.

The current carveout addresses and sizes are defined statically for each
device. The R5F processors do not have an MMU, and as such require the
exact memory used by the firmwares to be set-aside. The firmware images
do not require any RSC_CARVEOUT entries in their resource tables either
to allocate the memory for firmware memory segments.

Note that the R5F1 carveouts are needed only if the R5F cluster is
running in Split (non-LockStep) mode. The reserved memory nodes can be
disabled later on if there is no use-case defined to use the
corresponding
remote processor.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20231001181417.743306-7-a-nandan@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Two carveout reserved memory nodes each have been added for each of the
C71x DSP for the TI J721S2 EVM boards. These nodes are assigned to the
respective rproc device nodes as well. The first region will be used as
the DMA pool for the rproc device, and the second region will furnish the
static carveout regions for the firmware memory.

The current carveout addresses and sizes are defined statically for each
device. The C71x DSP processor supports a MMU called CMMU, but is not
currently supported and as such requires the exact memory used by the
firmware to be set-aside.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20231001181417.743306-6-a-nandan@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Two carveout reserved memory nodes each have been added for each of the
R5F remote processor device within both the MCU and MAIN domains for the
TI J721S2 EVM boards. These nodes are assigned to the respective rproc
device nodes as well. The first region will be used as the DMA pool for
the rproc device, and the second region will furnish the static carveout
regions for the firmware memory.

The current carveout addresses and sizes are defined statically for each
device. The R5F processors do not have an MMU, and as such require the
exact memory used by the firmwares to be set-aside. The firmware images
do not require any RSC_CARVEOUT entries in their resource tables either
to allocate the memory for firmware memory segments.

Note that the R5F1 carveouts are needed only if the R5F cluster is running
in Split (non-LockStep) mode. The reserved memory nodes can be disabled
later on if there is no use-case defined to use the corresponding
remote processor.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20231001181417.743306-5-a-nandan@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

The K3 J721S2 SoCs have two C71x DSP subsystems in MAIN voltage domain. The
C71x DSPs are 64 bit machine with fixed and floating point DSP operations.
Similar to the R5F remote cores, the inter-processor communication
between the main A72 cores and these DSP cores is achieved through
shared memory and Mailboxes.

The following firmware names are used by default for these DSP cores,
and can be overridden in a board dts file if desired:
        MAIN C71_0 : j721s2-c71_0-fw
        MAIN C71_1 : j721s2-c71_1-fw
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20231001181417.743306-4-a-nandan@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

The J721S2 SoCs have 2 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters in MAIN voltage domain. Each of these can be
configured at boot time to be either run in a LockStep mode or in an
Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). The TCMs of both Cores are
combined in LockStep-mode to provide a larger 128 KB of memory, but
otherwise are functionally similar to those on J721E SoCs.

Add the DT nodes for the MAIN domain R5F cluster/subsystems, the two
R5F cores are added as child nodes to each of the R5F cluster nodes.
The clusters are configured to run in LockStep mode by default, with
the ATCMs enabled to allow the R5 cores to execute code from DDR
with boot-strapping code from ATCM. The inter-processor communication
between the main A72 cores and these processors is achieved through
shared memory and Mailboxes.

The following firmware names are used by default for these cores, and
can be overridden in a board dts file if desired:
  MAIN R5FSS0 Core0: j721s2-main-r5f0_0-fw (both in LockStep & Split mode)
  MAIN R5FSS0 Core1: j721s2-main-r5f0_1-fw (needed only in Split mode)
  MAIN R5FSS1 Core0: j721s2-main-r5f1_0-fw (both in LockStep & Split mode)
  MAIN R5FSS1 Core1: j721s2-main-r5f1_1-fw (needed only in Split mode)
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20231001181417.743306-3-a-nandan@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

The J721S2 SoCs have a dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/cluster in MCU voltage domain. It can be configured at boot
time to be either run in a LockStep mode or in an Asymmetric Multi
Processing (AMP) fashion in Split-mode. These subsystems have 64 KB
each Tightly-Coupled Memory (TCM) internal memories for each core
split between two banks - ATCM and BTCM (further interleaved into
two banks). The TCMs of both Cores are combined in LockStep-mode to
provide a larger 128 KB of memory, but otherwise are functionally
similar to those on J721E SoCs.

Add the DT nodes for the MCU domain R5F cluster/subsystem, the two R5F
cores are added as child nodes to each of the R5F cluster nodes. The
clusters are configured to run in LockStep mode by default, with the
ATCMs enabled to allow the R5 cores to execute code from DDR with
boot-strapping code from ATCM. The inter-processor communication between
the main A72 cores and these processors is achieved through shared memory
and Mailboxes.

The following firmware names are used by default for these cores, and
can be overridden in a board dts file if desired:
  MCU R5FSS0 Core0: j721s2-mcu-r5f0_0-fw (both in LockStep and Split mode)
  MCU R5FSS0 Core1: j721s2-mcu-r5f0_1-fw (needed only in Split mode)
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20231001181417.743306-2-a-nandan@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Currently J721E defines only the main_esm in DTS. Add node for mcu_esm
as well.

According to J721E TRM (12.11.2.2 ESM Environment) [1], we see that the
interrupt line from ESMi (main_esm) is routed to MCU_ESM (mcu_esm). This
is MCU_ESM0_LVL_IN_95 with interrupt ID 95. Configure mcu_esm
accordingly so that errors from main_esm are routed to mcu_esm and
handled.

[1] https://www.ti.com/lit/zip/spruil1Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230926142810.602384-1-n-francis@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Seems like the address value of the reg property was mistyped.
Update reg to 0x9ca00000 to match node's definition.

Fixes: f5a731f0 ("arm64: dts: ti: Add k3-am625-beagleplay")
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Reviewed-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230925151444.1856852-1-w.egorov@phytec.deSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

A TCA9554 GPIO expander is present on I2C0. Add it.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20230923080046.5373-3-rogerq@kernel.orgSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Keep the DPI to MIPI-DSI bridge disabled in the SoM dtsi file.

The display chain is not wholly described in the device tree file, on
Verdin product family the displays are additional accessories that are
configured/enabled using DT overlays.

With this enabled we have issues when a display is enabled on
TIDSS port1 (LVDS) and port0 (DSI) is not used.

Fixes: 9e772003 ("arm64: dts: ti: verdin-am62: Add DSI display support")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20230922123003.25002-1-francesco@dolcini.itSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

AM654 baseboard has two TCA9554 I/O expander on the WKUP_I2C0 bus.
The expander at address 0x38 is used to detect daughter cards.
Add a node for this I/O expander.
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230920053834.21399-1-r-gunasekaran@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Wth commit 16b26f60 ("rtc: rv3028: Use IRQ flags obtained from device
tree if available") we can now use the interrupt pin of the RTC.
Let's add interrupt pin definitions to the SoM RTC.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20230914093027.3901602-1-w.egorov@phytec.deSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Use single instead of double tab.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20230912133036.257277-1-w.egorov@phytec.deSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Specify the base dtb file k3-j721s2-common-proc-board.dtb on which the
k3-j721s2-evm-gesi-exp-board.dtbo overlay has to be applied. Name the
resulting dtb as k3-j721s2-evm.dtb.

Fixes: cac04e27 ("arm64: dts: ti: k3-j721s2: Add overlay to enable main CPSW2G with GESI")
Reported-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://lore.kernel.org/r/20230912043308.20629-1-s-vadapalli@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

bootph-all as phase tag was added to dt-schema
(dtschema/schemas/bootph.yaml) to describe various node usage during
boot phases with DT.

Describe the same for AM642-sk boot devices.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230911172902.1057417-4-nm@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

bootph-all as phase tag was added to dt-schema
(dtschema/schemas/bootph.yaml) to describe various node usage during
boot phases with DT.

Describe the same for AM642-evm boot devices.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230911172902.1057417-3-nm@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

bootph-all as phase tag was added to dt-schema
(dtschema/schemas/bootph.yaml) to describe various node usage during
boot phases with DT.

On TI K3 AM642 SoC, only esm nodes are exclusively used by R5
bootloader, rest of the dts nodes with bootph-* are used by later boot
stages also.

Add bootph-all for all other nodes that are used in the bootloader on
K3 AM642 SoC, and bootph-pre-ram is not needed specifically for any
other node in kernel dts.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230911172902.1057417-2-nm@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

bootph-all as phase tag was added to dt-schema
(dtschema/schemas/bootph.yaml) to describe various node usage during
boot phases with DT.

Describe the same for am625-sk boot devices.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230911162535.1044560-4-nm@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

bootph-all as phase tag was added to dt-schema
(dtschema/schemas/bootph.yaml) to describe various node usage during
boot phases with DT.

Describe the same for beagleplay boot devices.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230911162535.1044560-3-nm@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

bootph-all as phase tag was added to dt-schema
(dtschema/schemas/bootph.yaml) to describe various node usage during
boot phases with DT.

On TI K3 AM625 SoC, only secure_proxy_sa3 and esm nodes are
exclusively used by R5 bootloader, rest of the dts nodes with bootph-* are
used by later boot stages also.

Add bootph-all for all other nodes that are used in the bootloader on
K3 AM625 SoC, and bootph-pre-ram is not needed specifically for any
other node in kernel dts.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230911162535.1044560-2-nm@ti.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Add NXP IW416 based u-blox MAYA-W1 Bluetooth (using btnxpuart) as used
on the V1.1 SoMs. Wi-Fi is and was already using mwifiex.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Link: https://lore.kernel.org/r/20230901133233.105546-1-marcel@ziswiler.comSigned-off-by: Vignesh Raghavendra <vigneshr@ti.com>

Pull drm ci scripts from Dave Airlie:
 "This is a bunch of ci integration for the freedesktop gitlab instance
  where we currently do upstream userspace testing on diverse sets of
  GPU hardware. From my perspective I think it's an experiment worth
  going with and seeing how the benefits/noise playout keeping these
  files useful.

  Ideally I'd like to get this so we can do pre-merge testing on PRs
  eventually.

  Below is some info from danvet on why we've ended up making the
  decision and how we can roll it back if we decide it was a bad plan.

  Why in upstream?

   - like documentation, testcases, tools CI integration is one of these
     things where you can waste endless amounts of time if you
     accidentally have a version that doesn't match your source code

   - but also like the above, there's a balance, this is the initial cut
     of what we think makes sense to keep in sync vs out-of-tree,
     probably needs adjustment

   - gitlab supports out-of-repo gitlab integration and that's what's
     been used for the kernel in drm, but it results in per-driver
     fragmentation and lots of duplicated effort. the simple act of
     smashing an arbitrary winner into a topic branch already started
     surfacing patches on dri-devel and sparking good cross driver team
     discussions

  Why gitlab?

   - it's not any more shit than any of the other CI

   - drm userspace uses it extensively for everything in userspace, we
     have a lot of people and experience with this, including
     integration of hw testing labs

   - media userspace like gstreamer is also on gitlab.fd.o, and there's
     discussion to extend this to the media subsystem in some fashion

  Can this be shared?

   - there's definitely a pile of code that could move to scripts/ if
     other subsystem adopt ci integration in upstream kernel git. other
     bits are more drm/gpu specific like the igt-gpu-tests/tools
     integration

   - docker images can be run locally or in other CI runners

  Will we regret this?

   - it's all in one directory, intentionally, for easy deletion

   - probably 1-2 years in upstream to see whether this is worth it or a
     Big Mistake. that's roughly what it took to _really_ roll out solid
     CI in the bigger userspace projects we have on gitlab.fd.o like
     mesa3d"

* tag 'topic/drm-ci-2023-08-31-1' of git://anongit.freedesktop.org/drm/drm:
  drm: ci: docs: fix build warning - add missing escape
  drm: Add initial ci/ subdirectory

Pull x86 fixes from Ingo Molnar:
 "Fix preemption delays in the SGX code, remove unnecessarily
  UAPI-exported code, fix a ld.lld linker (in)compatibility quirk and
  make the x86 SMP init code a bit more conservative to fix kexec()
  lockups"

* tag 'x86-urgent-2023-09-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/sgx: Break up long non-preemptible delays in sgx_vepc_release()
  x86: Remove the arch_calc_vm_prot_bits() macro from the UAPI
  x86/build: Fix linker fill bytes quirk/incompatibility for ld.lld
  x86/smp: Don't send INIT to non-present and non-booted CPUs

Pull x86 perf event fix from Ingo Molnar:
 "Work around a firmware bug in the uncore PMU driver, affecting certain
  Intel systems"

* tag 'perf-urgent-2023-09-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/uncore: Correct the number of CHAs on EMR